SOLUTION · REPLICATE TO MYSQL

Real-time data replication to MySQL from your operational databases

Committed changes from your systems of record land in MySQL continuously, through JDBC batches and staged bulk cycles, instead of waiting for the next batch job.

Gluesync by MOLO17 captures changes from Oracle, SQL Server, PostgreSQL, MongoDB, IBM i, and other heterogeneous sources with a dedicated agent per database, then writes them to MySQL through a target agent built on the official MySQL JDBC driver. Snapshots seed each table first, CDC follows as changes happen, and Core Hub, the Gluesync control plane, runs every pipeline from one web UI and REST API.

Start a Gluesync trial Talk to us

VENDOR COMPATIBILITY

Battle-tested on every MySQL you deliver to

The same Gluesync MySQL agent is tested against each vendor offering below, self-managed or fully managed, so delivery 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

Teams that need MySQL to reflect operations now, not after the nightly load

Application and analytics engineers who run MySQL behind web applications or reporting, who need current rows, the source keys kept intact, and a reviewed CREATE TABLE generated from the source definition when a table does not exist yet
Data platform leads who want one Core Hub for every source feeding MySQL, backed by best-in-class enterprise support, rated 4.9/5 by customers
Architects who choose the write path per table, optimized batches or native bulk load for snapshots and CDC, with agents deployed on Docker, Docker Compose, or Kubernetes next to each source
Engineers replacing a Debezium and JDBC sink stack or scheduled ELT scripts who want every source delivered to MySQL by one product, with snapshots and monitoring built in

THE PROBLEM

MySQL data that arrives in batches is already behind

MySQL databases behind web applications and reporting usually receive data through scheduled exports, cron-driven queries, or ELT jobs. Each run reads the production source again, and the copy in MySQL is only as fresh as the last run. Teams looking for real-time MySQL replication or a MySQL CDC pipeline usually compare managed ELT from Fivetran or Airbyte, a Debezium and Kafka stack with a JDBC sink, commercial replication such as Oracle GoldenGate or AWS DMS, or scripts they maintain themselves.

Gluesync addresses that with per-agent CDC into MySQL. A source agent reads each database's native change mechanism, Core Hub routes the changes, and the MySQL target agent applies them with JDBC batches or staged bulk cycles. Oracle to MySQL, SQL Server to MySQL, and PostgreSQL to MySQL pipelines share the same model, the same snapshot, and the same operations.

HOW IT WORKS

How Gluesync writes to MySQL

The write path: optimized batches and staged bulk load

The MySQL agent writes through the official MySQL JDBC driver, with optional TLS. It is a target agent: it applies the change stream from any Gluesync source agent in real time, in commit order per entity, after a snapshot seeds each table. Gluesync never writes one row at a time, and each entity uses one of two paths.

Optimized batches, never row by row: by default, changes are grouped into highly optimized JDBC batches applied in capture order, so each round-trip carries many rows and the server sees a predictable load. The chunk size is configurable on the target agent.
Native bulk load: switch it on per entity for the initial snapshot, for ongoing CDC, or both, as described below.

Native bulk load for snapshots and CDC

Bulk load is switched on per entity with two independent settings, one for the initial load and one for the ongoing change stream. Both can be changed on an existing entity without recreating it.

In each mirroring cycle Core Hub collects every insert, update, and delete and collapses events on the same primary key: an insert followed by a delete is skipped, and consecutive updates become one update. The agent creates a fresh temporary staging table for the cycle and fills it with multi-row INSERT statements. An optional update join fills columns the source log left out, then deletes keyed on the old key and inserts of the current values are applied to the destination table in one pass.

Snapshot first, then continuous CDC

Seed, then stream: each entity loads its full table, then follows the source agent's change mechanism.
TRUNCATE before snapshot: the target table is truncated before snapshot inserts by default, which gives a clean reload. The option can be turned off in the agent's advanced settings.
Pre and post SQL: SQL commands can run before and after the snapshot and before and after CDC, for session settings, constraint handling, or cleanup.

Schema, keys, and duplicate rows

Table creation: when a target table does not exist, Core Hub generates a CREATE TABLE from the source columns, data types, and primary key, converted to MySQL syntax. You review and edit the statement before it runs.
On duplicate key: Upsert, the default, overwrites the existing row with the incoming one. Skip keeps the existing row and reports the skipped keys in a notification. Fail stops the entity so someone can review it.

What your MySQL DBA sets up

Create a user for Gluesync and the schema it uses, then enter the connection in Core Hub. For the full statements, see the MySQL target setup guide ↗.

Create a user with read and write access to the destination database and tables. Grant it DDL rights where Core Hub creates tables or staging objects.
For native bulk load, set local_infile=1 in the [mysqld] section of the server configuration.
Create a schema for Gluesync and give the user access to it for metadata and bulk staging.
In Core Hub, enter the host or IP address, the port (3306 by default), the database name, and the user's credentials.
For Amazon RDS and other managed services, turn on TLS. Those services accept only SSL connections, and the agent takes a certificate path.

Architecture around Core Hub

Lightweight agents sit close to each source. Core Hub orchestrates them through its web UI and REST APIs and routes changes to the MySQL target agent. A pipeline groups the source agents, the MySQL agent, and the entities they replicate, and Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes. For event-stream topologies, see CDC streaming.

Explore the general CDC streaming architecture →

WRITE OPTIONS

The MySQL target agent: one agent, a write path per entity

MySQL has one Gluesync target agent. Every entity writes in optimized batches by default, and native bulk load through a temporary staging table can be switched on for its snapshot, its CDC, or both.

Agent	Write technique	Versions	Best for
MySQL agent ↗	Official MySQL JDBC driver writing optimized batches; native bulk load through a temporary staging table for snapshots and CDC	Any MySQL edition: Community, Enterprise, Percona, AWS RDS, and MaxScale endpoints	Any MySQL database fed from Oracle, SQL Server, PostgreSQL, MongoDB, or IBM i. Optimized batches by default, and native bulk load for snapshots and CDC, switched on per entity.

SOURCES AND TOPOLOGIES

Feed MySQL from the systems of record you already run

Any Gluesync source agent can feed MySQL. Open the integrations finder with MySQL pre-selected to see every source that pairs with it.

One Core Hub runs Oracle to MySQL, SQL Server to MySQL, and PostgreSQL to MySQL pipelines side by side, with the same snapshot, monitoring, and write settings for each. Gluesync keeps pace with your change volume at any scale, and MOLO17 Professional Services can help plan the write path and the cutover with your team.

Oracle to MySQL from the redo logs through LogMiner or XStream: see Oracle CDC
SQL Server to MySQL through Change Data Capture or Change Tracking: see SQL Server CDC
PostgreSQL to MySQL from the write-ahead log: see PostgreSQL CDC
MongoDB to MySQL from Change Streams: see MongoDB CDC

FAIR, HIGH-LEVEL COMPARISON

Where Gluesync fits among MySQL ingestion approaches

Approach	What buyers usually get	Where Gluesync fits
Fivetran and Airbyte	Managed or open-source ELT with MySQL destinations and large connector catalogs. Syncs run on a schedule, and change capture varies by source connector	Log-based capture for each source engine and continuous writes into MySQL, operated from one Core Hub with MOLO17 enterprise support
Debezium with Kafka Connect and a JDBC sink	Open-source capture into Kafka topics, then a JDBC sink that writes rows into MySQL. You run Connect, offsets, and schema changes, and usually a merge step into current-state tables	Changes applied to MySQL tables by key, with no Kafka cluster in the path. Read the Debezium alternative comparison
Oracle GoldenGate, AWS DMS, and Qlik Replicate	Commercial replication services with MySQL among their targets. Capture and load options differ by product and version	Agents deployed next to each source, native capture per engine, and staged bulk cycles into MySQL, all run from one Core Hub
MySQL native replication	Built into MySQL: replicas receive the binary log from a primary server. Other sources and destinations need separate tooling	Gluesync writes into MySQL from Oracle, SQL Server, PostgreSQL, MongoDB, and IBM i under one pipeline model, not only from another MySQL server
Scheduled ELT scripts	Full control. Your team owns the extract queries, staging files, MERGE logic, retries, and the load each run puts on the source database	Log-based capture, staged bulk cycles, snapshot restarts, and Core Hub monitoring, with no pipeline code to maintain. Read batch ETL vs real-time data replication

MySQL replication reading and related pages

What does replicating to MySQL with Gluesync involve?

A Gluesync source agent captures committed changes from your database through its native change mechanism, Core Hub routes them, and the MySQL target agent applies them to MySQL tables continuously after a snapshot seeds each table.

Does Gluesync bulk load into MySQL?

Yes, for the initial snapshot and for ongoing CDC, with a separate switch for each on every entity. Each cycle collapses changes per primary key, fills a temporary staging table with multi-row INSERT statements, and applies it to the destination table in one pass. Without bulk load, the agent writes in optimized JDBC batches.

Which sources can replicate to MySQL?

Any Gluesync source agent, including Oracle, SQL Server, PostgreSQL, MariaDB, MongoDB, and IBM i. The integrations finder on our website lists every pairing.

Does Gluesync upsert rows in MySQL?

Yes. Upsert is the default On duplicate key setting, so an incoming row overwrites the existing row with the same primary key. In bulk mode, Core Hub deletes the changed keys first and then inserts their current values.

Which MySQL versions and editions are supported?

Any MySQL version, including Community, Enterprise, and Percona editions, AWS RDS, and MaxScale endpoints.

How do we connect Gluesync to Amazon RDS for MySQL?

Turn on TLS in the agent settings. Amazon RDS and other managed services accept only SSL connections, and the agent takes a certificate path.

Can Gluesync create the tables in MySQL?

Yes. When a target table is missing, Core Hub generates a CREATE TABLE from the source definition, converted to MySQL syntax, and you review it before it runs.

REPLICATE TO A TARGET