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 数

0x00 前景介绍 该版本文档内容适用于 TiKV 3.0 之前版本；不包含使用 TiKV Titan engine 架构的内容 TiKV 节点磁盘占用主要为以下三个目录 {{deploy_dir}}/log TiKV 日志目录，目前日志 GC 需要单独脚本操

0x00 介绍 TiSpark 项目 2020 年会被姊妹家 TiFlash 升级替换 pingcap/TiSpark 项目地址，使用前阅读以下文档 TiSpark 用户指南（英文版本） 官方 Blog TiSpark 文档 0x01 部署 TiSpark 前情提要 tidb-ansible/roles/local/templates/binary_packages.yml.j2 下载连接 此处为 tispark 下载连

0x00 假设 新建机房网络频繁变更或公司内部要求禁止使用 IP 做为服务启动监听（大公司规划时喜欢使用 hostname/server name + domain 做为服务监听信息，配合公司内网 DNS 做跨地域运维

0x00 背景 物理网络在实际生产环境会存在 vlan、IP 集群部署可能横跨多台机器甚至横跨机房，在有离线或在线业务情况下应该怎么操作变更 IP 地址信息，配

0x00 缘来 Syncer 数据同步，会因为网络延迟与网络丢包、上下游压力过大等原因导致断开，这些场景本身是可重启恢复的。 最初与 TiDB 使用的 supervise 小工具，这个工具有个问

0x00 开头 测试机器环境配置比较低，使用 TiDB Join 表连接查询时偶尔会出现重启现象，按照官方指导查看问题原因说时 TiDB-server OOM 了，那么 OOM 是什么呢？为什么 OOM 啊？怎么才

0x00 测试 前段时间部署了一套 TiDB 数据库，只有单纯的数据库放养是肯定不行的。还要一些灾备方案满足删库跑路之后的恢复工作。 按照以往（mysql）经验有