TiDB-OPS

TiDB Binlog 部署以及问题处理

TiDB Binlog 安装部署可查看官方文档 TiDB-Binlog 部署方案

tidb_binlog_kafka_architecture

TiDB Binlog work flow

TiDB Binlog 使用注意事项

Drainer 配置文件内参数解释

-disable-dispatch 是否禁用拆分单个 binlog 的 sqls 的功能,如果设置为 true,则按照每个 binlog 顺序依次还原成单个事务进行同步(下游服务类型为 mysql,该项设置为 False)

false 的时候,drainer 会并发执行获取到的 dml 语句,在执行之前会更具主键检测是否冲突
如果是 true 的时候,drainer 是单线程执行 dml 语句,并且是严格按照事务 ID 顺序排序执行
下游如果是 MySQL,该值设为 true 并没有什么问题,即使语句出现冲突,drainer 也能感知并排序修复。下游如果是 protobuf,一种静态文件方式存储,建议是使用 flase ,这样可以完整一致性回放该 binlog
下游是 MySQL 的话,执行过程能保持原有顺序,设置为并发模式可以加快消费能力

通过 API 接口获取 binlog 信息


PUMP 日志


Drainer 日志

TiDB Binlog FAQ

  1. 更新下游的 SQL 是什么?为什么在下游的 MySQL 监控里看到同时有 delete 和 replace?
    • insert 会变成 replace
    • update 和 delete 会变成对应的 update 和 delete
  2. 小流量数据的更新机制是什么?一定要凑满 txn*size 吗?有没有超时机制?
    • 和 syncer 处理机制一样, size + timeout
  3. TiDB 的 binlog 的生成机制是什么?如果一台 TiDB 不可用 (比如磁盘满了),drainer 就会整个停掉吗?
    • 如果 TiDB 不可用,PUMP 会自己生成 faker binlog(也就是我说的无效数据流量),来推荐排序的进度,不会 block 其他有效 binlog 数据的进度;每 3 s 生成一个
  4. binlog 有没有 purge 的机制,防止磁盘被占满?
    • binlog 有自己的 GC 机制以及熔断 (KAFKA 版本)
    • 如果 GC 比较慢,建议加磁盘容量报警
  5. 日志里出现的 error rpc error: code = Unknown desc = unexpected EOFESC
    • rpc error / Drainer 需要去 PUMP 读取消息,有时候因为下游响应慢,或者 PUMP 没有消息就会超时,断开自动重试相应链接