0x00 上帝说有光 目标：持续 tidb.cc 域名的运转 初衷：让更多的人了解 xxxx 产品 内核：提升自身技能以及建立良性记录 动力：装逼 助力 OKR、分享与讨论技术的真实性、

0x00 - 背景 高可用性（英语：high availability，缩写为 HA）测试 failpoint 场景，需要在服务前面添加 load balance 组件；比如 F5、LVS、Haprox

0x00 开局 本文仅记录了对 DM 的学习，处理问题经验慢慢补充（没有素材编场景） 版本使用从 RC 到 v1.0.3 ；架构整体变化不大，有着上纲上线的框架守护 本页内容没有干

0x00 源 TiDB to TiKV 之间的网络状态(图片来自与 PingCAP 官网锁冲突)「该图包含悲观锁逻辑，来自 2020 年的 PingCAP 官网」；部分内容来自 Google Percolator 的事务模型。 0x01 2PC 2PC (Two-phaseCommit) 是指在计算机

0x00 CCC 单个不够，数量来凑，太多人跑也会不规划好跑道容易干架；使用 Linux 软件 numactl 将服务进程绑定在目标 CPU 上，支持按 Vcore、物理 CPU 绑定。 0x01 numactl numactl –show 查看当

0x01 precheck 本篇文档产生原因来自 Step 7: Configure the CPUfreq governor mode on the target machine 根据 TiDB-ansible 安装时的报错反推物理机安装 TiDB 时需要干点啥…… 0x02 OS 结合官方文档 使用 TiDB Ansible 部署 TiDB 集群 文档先整理

0x00 院子 MySQL 有个东东的叫 GTID（GTID = server_uuid:transaction_id）；它在 Binlog 文件中大概长这样【3E11FA55-7

0x00 监控 使用云机房物理机设备组建同城三中心方式部署 部署时已知 idc3 与其他两个机房 ping latency 稍高，大约在 1 - 3 ms 之间，idc1 与 idc2 机房延迟稳定在 1ms 以内 0x01 架

0x00 事前 维护该 Binlog 架构下的问题之一 “GC 数据问题” 0x01 FAQ-1 某天巡检发现以下现象，pump 还在工作、Drainer 写入出现中断 查看 Drainer 日志 1 2 3 4 5 6 pump.go:433:

0x00 元 收到监控 & 业务告警，内容为目前 QPS duration > 1s 首先排查监控缩小范围 交叉信息判定为 region 超过 144mb 以后未分裂，造成 get snapshot 持续失败，同时 region 过大造成写入和读取数

0x00 元 tidb ddl 3.0 版本之前只有一个队列提供服务，所有 ddl 都要在这个队列阻塞 多个 TiDB-server 会先选举 DDL owner TiDB 配置文件中的 run-ddl = false 该节点不支持运行 DDL DDL owner 处理所有 DDL 信息 更

0x00 告警 TiDB 与 TiKV 出现大量 backoff；触发 backoff 告警阈值 相应时间段 tidb kv error 监控趋势升高 相应时间段 tikv thread cpu / apply cpu 监控趋势升高 1 2 3 4 5 6 7 8 9 10 11 12 13 14

0x00 复古文档 根据 PK 查询不不到数据、根据其他索引字段可以查询到数据、根据 count 确认不同字段下数据量一致； 0x01 过程 先行随机校验数据 1 2 3 4 5 6 7 8 9 10 11

0x00 背景 长期使用 Syncer 之后经过一番胡思乱想之后的总结经验，类似于“久病成医”的感觉 内容按照 201706 - 201806 期间使用经验整理，后续大致是不会遇见了，因为有了新

0x00 借口 该问题出现时间为 2018 年 5 月 12 日，影响版本范围在 1.0.x & 2.0 附近；基本上算运维事故，一定要配置告警啊，就算系统不重要 现象总结 出现 crc mismatch 可能是 pump binlog 数