TiDB Binlog Relay Log

Drainer 同步 binlog 时会拆分上游的事务,并将拆分的事务并发同步到下游。在极端情况下,上游集群不可用并且 Drainer 异常退出后,下游集群(MySQL 或 TiDB)可能处于数据不一致的中间状态。在此场景下,Drainer 借助 relay log 可以确保将下游集群同步到一个一致的状态。

Drainer 同步时的一致性状态

下游集群达到一致的状态是指:下游集群的数据等同于上游设置了 tidb_snapshot = ts 的快照。

checkpoint 状态一致性是指:Drainer checkpoint 通过 consistent 保存了同步的一致性状态。Drainer 运行时 consistentfalse,Drainer 正常退出后 consistent 更新为 true

查询下游 checkpoint 表的示例如下:

mysql> select  * from tidb_binlog.checkpoint;
+---------------------+----------------------------------------------------------------+
| clusterID           | checkPoint                                                     |
+---------------------+----------------------------------------------------------------+
| 6791641053252586769 | {"consistent":false,"commitTS":414529105591271429,"ts-map":{}} |
+---------------------+----------------------------------------------------------------+

工作原理

Drainer 开启 relay log 后会先将 binlog event 写到磁盘上,然后再同步给下游集群。如果上游集群不可用,Drainer 可以通过读取 relay log 把下游集群恢复到一个一致的状态。

注意:

若同时丢失 relay log 数据,该方法将不可用,不过这是概率极小的事件。此外可以使用 NFS 等网络文件系统来保证 relay log 的数据安全。

Drainer 从 relay log 消费 binlog 的触发场景

如果 Drainer 启动时无法连接到上游集群的 PD,并且探测到 checkpoint 的 consistent = false,此时会尝试读取 relay log,并将下游集群恢复到一致的状态。然后 Drainer 进程将 checkpoint 的 consistent 设置为 true 后主动退出。

Relay log 的清理(GC)机制

Drainer 在运行时,如果确认已经将一个 relay log 文件的全部数据都成功同步到下游了,就会马上删除这个文件,所以 relay log 不会占用过多空间。一个 relay log 文件大小达到 10MB(默认)时就会做切分,数据开始写入新的 relay log 文件。

配置

在 Drainer 中添加以下配置来开启 relay log 功能:

[syncer.relay]
# 保存 relay log 的目录,空值表示不开启。
# 只有下游是 TiDB 或 MySQL 时该配置才有生效。
log-dir = "/dir/to/save/log"