号外,截止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套升级就是确保万无一失.

2. 集群负载情况

   • QPS读4K,写1K.
   • 数据存储:20T(Region 41W)
   • TiDB-4节点.PD-3节点.TiKV-13节点

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

4. 业务升级前准备:

   • 升级服务,保证升级期间增量数据灰度.
   • 业务原有事务重试逻辑校验

1.2.升级流程

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

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

   • pd-leader节点滚动升级瞬间,SQL整体时间拉长,接近不可用(秒级),pd-leader升级完毕SQL执行时间下降
   • TiKV强制升级(会发生数据读写请求Region找不到情况报错)
   • TiDB滚动升级(部分连接断开)

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

   • 失败重试订单是否成功
   • 与恢复增量数据比对

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

整体升级影响

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

2.其他使用小感悟

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

负载极高:

导致headrbeat的延时

单独部署问题解决

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

   • TiFlash承担OLAP磁盘一定要好,目前我们业务基本IO跑满
   • 即时是列存,对于业务的大表+大表关联有时候可能也要几十秒,同时这种操作非常消耗资源.

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

   

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