MySQL replication for reporting, recovery and migration, without touching the application

MySQL usually sits under an application the business cannot stop: a store, a booking system, a customer portal. When reports, a recovery site or a new platform need its data, MySQL data replication has to meet four conditions:

• No change to the application. Its team releases nothing for replication to work.
• Every change, in order. Inserts, updates and deletes arrive in commit order.
• Limited load. The initial copy and any catch-up stay inside an agreed limit.
• Proof. Counts and checksums show the target matches, and lag is measured.

Relatedchange data capture guide

Polling a "last changed" column misses deleted rows; triggers add work to every write. MySQL CDC (change data capture) normally reads the binary log, the record MySQL keeps of committed changes and the same one its built-in replication uses. Nothing is added to the application, so log-based capture is the usual choice for production. It asks a few things of the team that runs MySQL:

Streaming MySQL to Kafka lets new services react to an order or a payment without querying production. Apache Kafka is among the systems iblync's website lists; the pairing is confirmed in scoping. What makes the stream trustworthy:

• Topics and keys. One topic per table or entity, keyed by primary key, so each record's changes stay in order.
• Duplicates. After a restart a change can arrive twice; consumers handle repeats.
• Sensitive columns. Decide which may leave MySQL at all; mask or drop the rest.

iblync is Interkey's own data migration and replication platform, and MySQL is on its published connector list. It brings:

• Initial load, then continuous replication from a recorded log position, in commit order.
• Throttling, so replication does not compete with production, even while catching up.
• A queue that holds changes while the target is away.
• Resume and validation. iblync's site states that interrupted work resumes where it stopped and that validation uses checksums and row counts.
• Two-way sync for records written on both sides during a transition.

Relatedreal time replication page

• Reporting. Heavy queries move to a copy, so the application stays fast at month end; the business agrees how far the copy may lag.
• Disaster recovery. A standby at another site keeps the recovery point close. It is not a backup: a table dropped by mistake is dropped there too. Our disaster recovery page covers the wider plan.
• Migration. The new database is kept in step while it is proved, then writes move in a rehearsed cutover. For PostgreSQL, the MySQL to PostgreSQL page covers type mapping and Arabic text.

If your estate also runs other engines, the same method applies to PostgreSQL replication and SQL Server replication.

Relateddisaster recovery pageMySQL to PostgreSQL page

One team for scoping, capture, load, replication and monitoring, with support from Riyadh in Arabic and English. iblync is delivered with the team that operates it.

A replication stream is production data in motion, so residency applies to it. Many Saudi organisations must keep certain data inside the Kingdom under the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa). Where capture, queue and target run, and whether any data leaves your environment, is confirmed per engagement before the first row moves.

Relatednca.gov.sasdaia.gov.sa

We publish no price or duration for MySQL replication; the estate decides both:

• servers, tables and daily change volume;
• the number of targets and how far their models differ;
• the lag allowed;
• work on logging, primary keys and character sets;
• where the bridge runs;
• whether the stream is temporary or permanent.

Scoping turns these into a schedule range and a quotation.