| title | aliases | |||
|---|---|---|---|---|
TiDB Binlog Relay Log |
|
Drainer 同步 binlog 时会拆分上游的事务，并将拆分的事务并发同步到下游。在极端情况下，上游集群不可用并且 Drainer 异常退出后，下游集群（MySQL 或 TiDB）可能处于数据不一致的中间状态。在此场景下，Drainer 借助 relay log 可以确保将下游集群同步到一个一致的状态。
下游集群达到一致的状态是指：下游集群的数据等同于上游设置了 tidb_snapshot = ts 的快照。
checkpoint 状态一致性是指：Drainer checkpoint 通过 consistent 保存了同步的一致性状态。Drainer 运行时 consistent 为 false，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 启动时无法连接到上游集群的 PD，并且探测到 checkpoint 的 consistent = false，此时会尝试读取 relay log，并将下游集群恢复到一致的状态。然后 Drainer 进程将 checkpoint 的 consistent 设置为 true 后主动退出。
Drainer 在将数据同步到下游之前，会先将数据写入到 relay log 文件中。当一个 relay log 文件大小达到 10MB（默认）并且当前事务的 binlog 数据被写入完成后，Drainer 就会开始将数据写入到下一个 relay log 文件中。当 Drainer 将数据成功同步到下游后，就会自动清除当前正在写入的 relay log 文件以外其他已完成同步的 relay log 文件。
在 Drainer 中添加以下配置来开启 relay log 功能：
{{< copyable "" >}}
[syncer.relay]
# 保存 relay log 的目录，空值表示不开启。
# 只有下游是 TiDB 或 MySQL 时该配置才有生效。
log-dir = "/dir/to/save/log"
# 单个 relay log 文件大小限制（单位：字节）。
# 超出该值后会将 binlog 数据写入到下一个 relay log 文件。
max-file-size = 10485760