<!-- Generated from the rendered page by scripts/write-llm-mirrors.mjs. Do not edit by hand. -->
Canonical: https://molo17.com/solutions/mysql-cdc/
Markdown mirror: https://molo17.com/solutions/mysql-cdc/index.md
Title: MySQL CDC and real-time replication with Gluesync | MOLO17
Description: MySQL CDC from the binary log with Gluesync. Replicate changes continuously to warehouses, caches, and event streams, managed from one Core Hub. Start a trial.

[Solutions](/solutions/)  MySQL CDC

 SOLUTION · MYSQL CDC

# MySQL change data capture and real-time data replication

**Real-time MySQL CDC from the binary log, without scanning your tables.**

Gluesync by MOLO17 captures committed changes from MySQL with a dedicated source agent that reads the binary log. It delivers those changes continuously to the databases, warehouses, caches, and event streams your teams already run. Manage every pipeline from the Core Hub web UI, the Gluesync control plane.

[Start a Gluesync trial](/get-gluesync/) [Talk to us](/contacts/)

VENDOR COMPATIBILITY

## Battle-tested on every MySQL you run

The same Gluesync MySQL agent is tested against each vendor offering below, self-managed or fully managed, so capture behaves the same wherever MySQL runs.

-    **MySQL** Source Target Tested
-    **Amazon Aurora MySQL** Source Target Tested
-    **Amazon RDS for MySQL** Source Target Tested
-    **Google Cloud SQL MySQL** Source Target Tested
-    **Microsoft Azure Database for MySQL** Source Target Tested
-    **Oracle Cloud MySQL Instance** Source Target Tested

WHO THIS IS FOR

## MySQL teams moving operational data into modern systems

-   MySQL DBAs who must approve binary logging, a dedicated replication user, and a staging schema, with a short list of server settings and grants to review before anything touches production
-   Data platform leads feeding Snowflake, BigQuery, Amazon Redshift, data lakes, Kafka, or Redis from MySQL systems of record, who want one Core Hub for every source and target
-   Teams replacing nightly dumps, timestamp polling, or a commercial CDC license for MySQL with a supported path that does not require rebuilding pipelines
-   Engineers who prototyped the Debezium MySQL connector and now run Kafka Connect, offsets, and on-call for a pipeline the business treats as infrastructure

THE PROBLEM

## MySQL data that only moves in batches goes stale and loads production

MySQL often holds the system of record for web and SaaS applications, so scheduled exports and timestamp polling leave analytics and caches working from copies that are already behind, while each query competes with production. Buyers searching for MySQL CDC or real-time MySQL to Snowflake usually weigh the same options: MySQL's native replication keeps copies inside the MySQL family, Debezium means running Kafka Connect and everything around it, and cloud-managed migration services usually stay inside one cloud.

Gluesync addresses that pattern with **per-agent CDC**. A MySQL source agent reads the binary log, and target agents write to the destinations you choose. Each source system has its own agent and native change stream, and Core Hub runs the pipelines.

HOW IT WORKS

## How Gluesync does MySQL CDC

### Binary log streaming, not table scans

The MySQL agent reads changes from the binary log using MySQL's native binary log streaming protocol over a TCP socket. It connects through the built-in MySQL JDBC driver, which Gluesync bundles.

-   Row changes are consumed from the binary log as they are committed and forwarded to the target; an update that changes a primary key is applied as a delete plus an insert.
-   `TRUNCATE` operations are captured on read and forwarded to the target.
-   Before and after images are enabled automatically, so the agent can compare each row with its previous value.
-   The agent connects to a master, replica, or MaxScale endpoint and registers with the master under its own server ID.

### What your DBA enables

The agent needs binary logging on the server and a dedicated user. These are the settings, in order.

1.  In the `[mysqld]` section of the MySQL configuration file, set `server_id`, `log_bin`, and `binlog_format=ROW`, then restart MySQL.
2.  Create a dedicated user, then grant it `REPLICATION SLAVE` on `*.*` and `SELECT` on `mysql.innodb_table_stats` for table statistics.
3.  Give the same user permission to create and write tables in a staging schema, the temporary staging area.
4.  Enable TLS on the agent. AWS RDS, like other managed services, accepts connections only over SSL, so set Use SSL to true during setup.

### Resilience: cache, persisted positions, and technical fields

Source agents write changes to a local ArenaCache first. The MySQL reader stores its binary log position in Core Hub rather than in a local file, so moving or restarting the agent does not reset the reader. Prometheus metrics report that position as `binlogPosition` and `operationSeq`.

-   **Technical fields:** optionally add `TRANSACTION_ID`, `TRANSACTION_TIMESTAMP`, and `TRANSACTION_OPERATION` to the replicated data for audit and lineage.
-   **Recursion protection:** when enabled, the agent skips changes made by its own connection user, which matters in bi-directional setups.

### Architecture around Core Hub

Lightweight agents sit close to each system. Core Hub handles the web UI, the REST API, and routing between source and target agents. A pipeline groups a source agent, a target agent, and the entities they move. Each MySQL pipeline can start with a snapshot, which Core Hub runs as an initial load or re-sync, and then continue with CDC. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes.

[Explore the general CDC streaming architecture →](/solutions/cdc-streaming/)

CAPTURE OPTIONS

## The MySQL agent: one capture path for every MySQL source

MySQL has one Gluesync source agent. It reads the binary log for CDC and runs snapshots and target writes through the same Core Hub pipelines.

| Agent | Capture technique | Versions | Best for |
| --- | --- | --- | --- |
| [MySQL agent ↗](https://docs.molo17.com/gluesync/latest/agents/mysql-intro.html) | Binary log (binlog) streaming over a TCP socket, with the built-in JDBC driver | MySQL 5.7.25 and later, including 8.4; Community, Enterprise, Percona, AWS RDS, and MaxScale endpoints | Log-based capture from MySQL 5.7.25 or later when binary logging can be enabled in ROW format. |

TARGETS AND TOPOLOGIES

## Keep MySQL as the source while modernizing destinations

Use the [integrations directory](/integrations/?source=MySQL#integration-finder) to pair MySQL as a source with relational engines, NoSQL stores, cloud warehouses, object and lake storage, or event streams. The MySQL agent also works as a target over the built-in JDBC driver, with optional TLS. Bulk load into MySQL needs `local_infile=1` on the server.

Gluesync keeps pace with your change volume at any scale. [MOLO17 Professional Services](/solutions/professional-services/) can size the deployment with your team.

Target agents write in optimized batches, never row by row, and switch to native bulk load for both snapshots and CDC on targets such as [Snowflake](/solutions/replicate-to-snowflake/), [Google BigQuery](/solutions/replicate-to-bigquery/), [Amazon Redshift](/solutions/replicate-to-redshift/), [Microsoft SQL Server](/solutions/replicate-to-sql-server/), and [PostgreSQL](/solutions/replicate-to-postgresql/).

-   Offload reporting and API reads from MySQL to PostgreSQL or SQL Server: see [database offload](/solutions/database-offload/)
-   Land MySQL changes in Snowflake, BigQuery, Amazon Redshift, or a data lake as they happen: see [warehouse sync](/solutions/warehouse-sync/)
-   Publish MySQL changes to Apache Kafka or another event-streaming platform
-   Run a snapshot plus CDC to keep MySQL and a cloud target aligned until cutover: see [cloud migration](/solutions/cloud-migration/)

FAIR, HIGH-LEVEL COMPARISON

## Where Gluesync fits among MySQL CDC approaches

| Approach | What buyers usually get | Where Gluesync fits |
| --- | --- | --- |
| MySQL native replication | Built into MySQL and designed for copies between MySQL servers; the targets stay inside the MySQL family | One binary log reader feeds non-MySQL targets such as warehouses, caches, and streams, managed from one Core Hub |
| Debezium MySQL connector with Kafka | Open-source binlog-based capture; you run Kafka, Kafka Connect, offsets, and upgrades yourself | A productized MySQL agent with Core Hub operations and [best-in-class MOLO17 enterprise support (rated 4.9/5 by customers)](/support/#customer-ratings); read the [Debezium alternative](/solutions/debezium-alternative/) comparison |
| Qlik Replicate, Fivetran HVR, or similar commercial CDC | Mature replication portfolios with broad source coverage; packaging and licensing vary by product | One Core Hub for MySQL sources and many targets, with a documented MySQL capture path and one control plane for every target |
| Cloud-managed CDC services such as AWS DMS | Convenient inside one cloud; capture options and targets follow that provider | Agents run where MySQL runs, on-premises or in any cloud, and deliver to targets across providers |
| DIY exports, timestamp polling, or custom binlog readers | Full control with high build and operations cost; polling adds read load to production | A productized binlog agent with snapshots, persisted positions, and monitoring; read [batch ETL vs real-time data replication](/blog/batch-etl-vs-real-time-data-replication/) |

RELATED CONTENT

## MySQL CDC research and implementation detail

-   [Gluesync for MySQL 8+: high-performance change data capture](/blog/gluesync-for-mysql8-change-data-capture/)
-   [New MariaDB agent for Gluesync, and how it relates to MySQL](/blog/mariadb-agent-for-gluesync/)
-   [Batch ETL vs real-time data replication: how to choose](/blog/batch-etl-vs-real-time-data-replication/)
-   [CDC streaming without source overhead](/solutions/cdc-streaming/)
-   [Debezium alternative: managed CDC versus Kafka + Debezium](/solutions/debezium-alternative/)
-   [MySQL agent overview ↗](https://docs.molo17.com/gluesync/latest/agents/mysql-intro.html)
-   [MySQL CDC setup and configuration ↗](https://docs.molo17.com/gluesync/latest/agents/mysql-change-data-capture.html)
-   [Target MySQL setup ↗](https://docs.molo17.com/gluesync/latest/agents/mysql-target.html)

FAQ

## MySQL CDC questions

What is MySQL CDC with Gluesync?

Change data capture from MySQL by reading committed changes from the binary log with the MySQL agent, then delivering inserts, updates, deletes, and truncates to configured targets through Core Hub.

Which MySQL versions does the MySQL agent support?

MySQL 5.7.25 and later, including 8.4. The agent works with Community, Enterprise, and Percona editions, with AWS RDS for MySQL, and with MaxScale endpoints.

What does the DBA have to enable on the MySQL server?

Binary logging in ROW format, with server\_id and log\_bin set in the MySQL configuration and a restart. Then a dedicated user with REPLICATION SLAVE and SELECT on mysql.innodb\_table\_stats, plus create and write permission in a staging schema.

Can Gluesync read from a replica or a MaxScale endpoint?

Yes. Master, replica, and MaxScale endpoints are all supported connection points, and the agent registers with the master under its own server ID.

Does Gluesync work with managed MySQL services?

Yes. The MySQL agent is tested against Amazon Aurora MySQL, Amazon RDS for MySQL, Google Cloud SQL for MySQL, Azure Database for MySQL, and Oracle Cloud MySQL. Enable binary logging and set Use SSL to true, because managed services accept only TLS connections.

Which changes does the MySQL agent capture, and does it do an initial load?

The agent captures inserts, updates, deletes, and TRUNCATE operations from the binary log, and it enables before and after images automatically. For the initial load, Core Hub snapshot tasks copy the existing data, and re-syncs use the same mechanism.

Can Gluesync write to MySQL, not only read from it?

Yes. The MySQL agent supports the target role over the built-in JDBC driver. Bulk load needs local\_infile=1 on the server.

Where should we start?

Start a Gluesync trial to test the MySQL agent against your version, topology, and targets. Or talk to MOLO17 before you change any server settings, so the binary logging and grant changes match your DBA policy.

CDC BY SOURCE DATABASE

## Other sources Gluesync captures from

-    [Cosmos DB CDC](/solutions/cosmos-db-cdc/)
-    [Couchbase CDC](/solutions/couchbase-cdc/)
-    [Db2 LUW CDC](/solutions/db2-luw-cdc/)
-    [DynamoDB CDC](/solutions/dynamodb-cdc/)
-    [IBM i CDC](/solutions/ibm-i-cdc/)
-    [Informix CDC](/solutions/informix-cdc/)
-    [MariaDB CDC](/solutions/mariadb-cdc/)
-    [MongoDB CDC](/solutions/mongodb-cdc/)
-    [Oracle CDC](/solutions/oracle-cdc/)
-    [PostgreSQL CDC](/solutions/postgresql-cdc/)
-    [SAP ASE (Sybase) CDC](/solutions/sap-ase-cdc/)
-    [SAP HANA CDC](/solutions/sap-hana-cdc/)
-    [ScyllaDB CDC](/solutions/scylladb-cdc/)
-    [SQL Server CDC](/solutions/sql-server-cdc/)
-    [YugabyteDB CDC](/solutions/yugabytedb-cdc/)

## Evaluate Gluesync with your MySQL binary logs

Start a trial on your infrastructure, or talk to MOLO17 about your MySQL version, topology, managed service, and targets.

[Start a Gluesync trial](/get-gluesync/) [Talk to MOLO17](/contacts/)
