TiDB Binlog Relay Log

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

Drainer 同步时的一致性状态

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

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

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

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

工作原理

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 文件大小达到 10MB（默认）并且当前事务的 binlog 数据被写入完成后，Drainer 就会开始将数据写入到下一个 relay log 文件中。当 Drainer 将数据成功同步到下游后，就会自动清除当前正在写入的 relay log 文件以外其他已完成同步的 relay log 文件。

配置

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

  1. [syncer.relay]
  2. # 保存 relay log 的目录，空值表示不开启。
  3. # 只有下游是 TiDB 或 MySQL 时该配置才有生效。
  4. log-dir = "/dir/to/save/log"
  5. # 单个 relay log 文件大小限制（单位：字节）。
  6. # 超出该值后会将 binlog 数据写入到下一个 relay log 文件。
  7. max-file-size = 10485760