作者： 天赐小郑原文来源：https://tidb.net/blog/4ed252db

号外, 截止 2020 年 9 月 23 日 19:10 分,58 同城 TiDB 集群共计 52 套, 存储总量 120T, 共 297 台服务器.All in v4.0.2. 其中最核心的 PMC 订单流水业务与 2020 年 9 月 23 日 19:00 开始升级,19:10 分升级完成. 历时一个季度的 TiDB 升级工作全部完成,58TiDB 小组完美完成季度任务. 谨以此贴感谢于老大的大力支持, 组长 (刘春雷), 组员 (高歌) 的勠力同心, 官方人员的全程辅助!(房老师, 李仲舒, 王贤净, 李德竹, 韦万等小伙伴).

1. 升级流程

1.1. 集群 && 业务介绍

1.PMC 订单流水业务是 58TiDB 最最核心的业务 (涉及 money 的都是大事), 数据一行都丢不了. 升级前 v3.0.6, 放在第 52 套升级就是确保万无一失.

1. 集群负载情况

2. QPS 读 4K, 写 1K.

3. 数据存储:20T(Region 41W)

4. TiDB-4 节点.PD-3 节点.TiKV-13 节点

1. 升级方式选择: 由于集群数据量级过大, 为了避免正常滚动升级迁移 region 的时间导致整体升级时间过长 (估计正常 1 小时下不来), 跟业务沟通为了减少服务不可用时间, 使用 tuip cluster upgrade –force 强制升级.

2. 业务升级前准备:

3. 升级服务, 保证升级期间增量数据灰度.

4. 业务原有事务重试逻辑校验

1.2. 升级流程

1. 19:00 分开始执行升级命令 tiup cluster upgrade 20000_pmc v4.0.2 --force并告知业务

2. 观察集群升级滚动情况

3. pd-leader 节点滚动升级瞬间,SQL 整体时间拉长, 接近不可用 (秒级),pd-leader 升级完毕 SQL 执行时间下降

4. TiKV 强制升级 (会发生数据读写请求 Region 找不到情况报错)

5. TiDB 滚动升级 (部分连接断开)

6. 19:09 升级完毕, 业务校验数据

7. 失败重试订单是否成功

8. 与恢复增量数据比对

9. 校验完成, 继续观察集群情况, 升级后全程稳定

整体升级影响

结论: 对于本次核心业务的升级, 使用强制升级下的 TiDB 整体表现非常棒!PD-leader 升级期间也只是瞬时不可用, 后续强制升级 TiKV 的业务重试全部成功.20T 的数据集群仅用 9 分钟升级完毕. 给官方比心❤️

2. 其他使用小感悟

1. PD 建议单独部署或者容器化部署: 随着业务量级增大,Region 数量增多 (集群最大 123W), 在单台服务器混合部署 PD 集群导致 PD 响应时间大大增加, 从而影响业务, 建立容器化. 业务因此受到过影响, 最后选择单独部署解决问题.(PS:TiDB 节点同理)

负载极高:

导致 headrbeat 的延时

单独部署问题解决

1. TiFlash 部署大数据量集群不要随意切换 pd-leader(v4.0.2)

2. TiFlash 承担 OLAP 磁盘一定要好, 目前我们业务基本 IO 跑满

3. 即时是列存, 对于业务的大表 + 大表关联有时候可能也要几十秒, 同时这种操作非常消耗资源.

4. 一定约束业务. 即使分布式集群也不要随意使用, 比如 insert 或者 update 操作 value 值超过 200 或者字节太多. 一般集群单点部署响应变慢大多是 SQL 问题

最后, 如有解释不当之处敬请各路大佬指正.