reference/tidb-binlog: add docs about relay log

dev/reference/tidb-binlog/deploy.md

@@ -539,6 +539,13 @@ Drainer="192.168.0.13"
 
         # replicate-do-db = ["~^b.*","s1"]
 
+        # [syncer.relay]
+        # 保存 relay log 的目录，空值表示不开启。
+        # 只有下游是 TiDB/MySQL 配置才有意义。
+        # log-dir = ""
+        # 每个文件的最大大小
+        # max-file-size = 10485760
+
         # [[syncer.replicate-do-table]]
         # db-name ="test"
         # tbl-name = "log"
@@ -612,6 +619,42 @@ Drainer="192.168.0.13"
 
         如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。
 
+# 关于 Relay log
+
+drainer 会拆分上游的事务并发写下游，在极端情况上游集群不可用并且 drainer 异常退出后，同步的下游集群（MySQL/TiDB）可能处于数据不一致的中间状态。
+
+下游集群达到一致的状态的定义为：
+
+* 下游集群的数据等同于设置了 _tidb_snapshot = ts_ 的快照上游 TiDB 集群的数据
+
+当 drainer 开启 relay log 后会先将 binlog event 写到磁盘上，然后再同步给下游集群。如果上游集群不可用，我们总是可以通过 relay log 把集群恢复到一个一致的状态。除非同时丢失 relay log 数据，不过这是概率极小的事件。此外可以使用 nfs 等网络文件系统来保证 relay log 的数据安全。
+
+relay log 会尽可能快的删除已经同步到下游的 binlog event，所以不会占很多磁盘空间。
+
+下游报存的 checkpoint 可以看到 status 状态, 0 表示达到一致的状态。drainer 运行时会是 1，正常退出后会更新为 0。
+
+```
+mysql> select * from tidb_binlog.checkpoint;
++---------------------+--------------------------------------------------------+
+| clusterID           | checkPoint                                             |
++---------------------+--------------------------------------------------------+
+| 6791641053252586769 | {"status":0,"commitTS":414529105591271429,"ts-map":{}} |
++---------------------+--------------------------------------------------------+
+```
+
+当 drainer 启动时连接不上上游集群的 PD 并且探测到 checkpoint 的 status 为 1 , 会尝试读取 relay log 将下游集群恢复到一个一致的状态，然后 drainer 进程将 checkpoint 的 status 设置为 0 后主动退出。
+
+## 配置
+
+开启 relay log 功能只需要在 drainer 添加如下配置:
+
+```
+[syncer.relay]
+# 保存 relay log 的目录，空值表示不开启。
+# 只有下游是 TiDB/MySQL 配置才有意意义。
+log-dir = "/dir/to/save/log"
+```
+
 > **注意：**
 >
 > - 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。