MySQL‑to‑DBLE Data Synchronization Using DTLE: Full and GTID‑Based Incremental Sync Guide

Background – A client needed to migrate a high‑traffic MySQL database to the distributed DBLE system with minimal downtime, requiring both an initial bulk load and continuous real‑time replication.

Environment preparation

Deploy DBLE 3.20.10.8 cluster (sharding.xml, db.xml, user.xml) – see configuration snippets below.

Create identical test tables on source MySQL and target DBLE.

Install a single‑node DTLE package via RPM.

Configuration files

<?xml version="1.0"?>
<!DOCTYPE dble:sharding SYSTEM "sharding.dtd">
<dble:sharding xmlns:dble="http://dble.cloud/" version="4.0">
  ... (sharding.xml content) ...
</dble:sharding>

<?xml version="1.0"?>
<!DOCTYPE dble:db SYSTEM "db.dtd">
<dble:db xmlns:dble="http://dble.cloud/" version="4.0">
  ... (db.xml content) ...
</dble:db>

<?xml version="1.0"?>
<!DOCTYPE dble:user SYSTEM "user.dtd">
<dble:user xmlns:dble="http://dble.cloud/" version="4.0">
  ... (user.xml content) ...
</dble:user>

Test table creation (MySQL)

use ren;
CREATE TABLE `test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
  `city` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
  `dt` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_ctiy` (`city`)
) ENGINE=InnoDB;

Full synchronization

Prepare a Nomad job file ( job.json ) that defines source MySQL and destination DBLE tasks.

Load initial data into the source table.

Submit the job with curl -XPOST "http://127.0.0.1:4646/v1/jobs" -d @job.json .

Verify that all rows appear in DBLE.

GTID‑based incremental synchronization

Stop the full‑sync job.

Record the source GTID set via SHOW MASTER STATUS\\G .

Create a new job file that includes the recorded GTID in the Gtid field.

Submit the incremental job and confirm that only changes after the GTID point are replicated.

Additional DML/DDL sync verification

Execute INSERT, UPDATE, DELETE on the source and confirm they propagate.

Apply ALTER TABLE and CREATE INDEX on the source; DBLE reflects the changes.

Configuration notes

Connection‑failure detection may require DBLE ≥ 3.20.10.6 (set autocommit issue).

Ensure the gtid_executed_v4 metadata table exists; adjust source_uuid column size if “Data too long” errors occur.

Conclusion

DTLE can reliably handle MySQL‑to‑DBLE migration, but for large production datasets the recommended workflow is to export a logical backup, split and import it into DBLE, then use GTID‑based incremental sync for ongoing changes.