Status

• Current status:
• Target component: Flink CDC MySQL Connector
• Tracking issue: FLINK-34807

一、Abstract

本提案为 Flink CDC MySQL Connector 增加 MariaDB GTID 方言支持，使 connector 能够识别、记录、比较并恢复 MariaDB 的 domain-server-sequence GTID。在数据库主从切换、迁移、扩缩容或云数据库代理将同一 endpoint 路由到另一物理节点时，只要 GTID domain 保持不变且新节点包含 checkpoint 所需的 sequence，任务就可以使用 checkpoint 中的逻辑位置恢复，而不依赖已经变化的 binlog 文件名、文件 offset 或 GTID 中的 server ID。

该实现不改变 MySQL UUID/interval GTID 路径，而是通过可配置的 dialect、独立的 GTID strategy、MariaDB 专用 binlog client 和 MariaDB GTID event 处理逻辑接入现有 Flink CDC/Debezium streaming pipeline。

二、Motivation

MySQL 和 MariaDB 都提供 GTID，但两者的数据模型、系统变量和复制协议并不兼容。

MySQL GTID 的典型形式为：

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

MariaDB GTID 的形式为：

domain-server-sequence
1-100-500

现有 MySQL Connector 的 GTID 逻辑基于 MySQL GtidSet、@@GLOBAL.gtid_executed、@@GLOBAL.gtid_purged 及 MySQL binlog dump 协议。直接把 MariaDB GTID 交给该路径会产生以下问题：

1. MySQL GTID parser 无法表达 MariaDB 的 domain 语义。
2. MariaDB 的当前 GTID 位置来自 @@gtid_binlog_pos，而不是 MySQL 的 GTID variables。
3. 云数据库的 proxy endpoint 可以保持不变，但背后的主库或从库物理节点、binlog 文件和 server ID 会变化。
4. mysql-binlog-connector-java 0.27.2 默认使用 @mariadb_slave_capability=1，不足以让 CDC reader 持续获得每个事务的 MARIADB_GTID event，因此 checkpoint 中的 GTID 无法随事务推进。
5. 如果恢复仍依赖旧物理节点的 binlog file/position，节点切换后即使逻辑事务连续，也可能因为找不到旧文件而失败。
6. 对于云数据库这种提供 proxy IP，多个从库。由于 LB 规则，不同 TM 会映射不同的真实物理节点。这就导致任务哪怕不做变更，遇到一些异常情况一旦发生重启，基于 File/Position 的任务无法自愈，这是我们生产不可接受的。（也是我要提交这个 PR 的原因）