Status

1. Abstract

This proposal adds MariaDB GTID dialect support to the Flink CDC MySQL Connector, enabling the connector to recognize, record, compare, and restore MariaDB domain-server-sequence GTIDs. During database primary/replica failover, migration, scaling, or when a cloud database proxy routes the same endpoint to another physical node, the job can restore from the logical position in the checkpoint as long as the GTID domain remains unchanged and the new node contains the sequence required by the checkpoint. Recovery therefore does not depend on changed binlog file names, file offsets, or the server ID in the GTID.

The implementation does not change the MySQL UUID/interval GTID path. Instead, it integrates with the existing Flink CDC/Debezium streaming pipeline through a configurable dialect, an independent GTID strategy, a MariaDB-specific binlog client, and MariaDB GTID event processing.

2. Motivation

MySQL and MariaDB both provide GTIDs, but their data models, system variables, and replication protocols are incompatible.

A typical MySQL GTID has the following form:

UUID:txn(interval)
24DA167-0C0C-11E8-8442-00059A3C7B00:1-19

A MariaDB GTID has the following form:

domain-server-sequence
1-100-500

The existing MySQL Connector GTID logic is based on the MySQL GtidSet, @@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged, and the MySQL binlog dump protocol. Passing MariaDB GTIDs directly into this path causes the following problems:

  1. The MySQL GTID parser cannot represent MariaDB domain semantics.
  2. The current MariaDB GTID position comes from @@gtid_binlog_pos rather than MySQL GTID variables.
  3. A cloud database proxy endpoint can remain stable while the physical primary or replica, binlog files, and server ID behind it change.
  4. mysql-binlog-connector-java 0.27.2 uses @mariadb_slave_capability=1 by default, which is insufficient for the CDC reader to continuously receive the MARIADB_GTID event for every transaction. Consequently, the GTID stored in the checkpoint cannot advance with transactions.
  5. If recovery still depends on the old physical node's binlog file/position, it may fail after a node switch because the old file cannot be found even when the logical transaction stream is continuous.
  6. Cloud databases commonly expose a proxy IP backed by multiple replicas. Under load-balancing rules, after a job restarts, a source reader running in a different task attempt or on a different TM may be mapped by the same endpoint to a different physical node. As a result, even without an explicit database change, a File/Position-based job may be unable to self-recover after an exceptional restart. This is unacceptable in our production environment and is the reason for submitting this PR.