{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/how-to-upgrade-tidb-happily",
    "result": {"pageContext":{"blog":{"id":"Blogs_334","title":"有关 TiDB 升级的二三事——教你如何快乐升级","tags":["升级"],"category":{"name":"案例实践"},"summary":"TiDB 技术团队提供了一组功能完善的升级工具包，从简单的参数比对到全场景的模拟重放，完全可以根据实际需求和成本考量自主选择一种最佳的搭配方案，为升级操作保驾护航。这套工具包实际上也已成功应用在了一款使用量过亿的用户 K8s 集群升级上，本文将会介绍这个用户案例。","body":"## 升级的苦与乐\n作为 TiDB 的老用户，相信你在使用 TiDB 的时候，总有可能会遇到需要对数据库进行升级的情况。一方面是**因为 TiDB 本身是个快速迭代的产品，新版本的新特性能很好地解决实际业务中的问题**；又**或者是当前使用的版本遇到某个安全漏洞或 Bug，需要高质量更稳定的新版本支持**。无论是哪种情况，升级都被提上了议事日程。\n\n但是作为数据库老玩家的你，应该很清楚升级本身就是存在一定风险的操作，比如：新版本中存在一些新的配置参数需要你去了解和适配，配的不好可能会出问题；新版本修复了安全漏洞，严格了安全权限，有些旧版本支持的访问模式也需要随之改写；之前一些 SQL 的执行计划好不容易的通过各种手段稳定下来，但是新版本也带来了不确定性。这就像你去了若指掌的餐馆点餐，突然间发现换了一个厨师，新师傅可能是米其林的大厨，但那道菜是不是你喜欢的口味却因人而异。总之你和我的想法一样，希望升级或迁移是平安的，顺利的，甚至是无感的。以至于某天业务找到你的时候不是抱怨突然出现的问题，而是称赞系统最近好用了很多，这才是升级最终的目的和价值。\n\n## TiDB 的百宝箱\n那如何保证你的升级是平安顺利的呢？TiDB 技术团队提供了一组功能完善的升级工具包，**从简单的参数比对到全场景的模拟重放，你完全可以根据你的实际需求和成本考量自主选择一种最佳的搭配方案，为你的升级操作保驾护航**。这套工具包实际上也已成功应用在了一款使用量过亿的用户 K8s 集群升级上，在之后的篇幅中我们会介绍这个用户案例。接下来我们先看看这些工具都是什么：\n\n- **TiDBA** 通过对比升级前后版本的参数，帮助你快速识别出新版本参数的变化。\n- **Pt-upgrade** 用于mysql/maria/aurora等很多商业客户的升级中，经过大量实践确定是可用且可靠的。percona consulting团队的主要工具。该工具使用 slow query log 在升级的源集群（旧版本）和目标集群（新版本）上同步回放，以测试 SQL 兼容性。\n- **Plan Change Capturer（PCC）** 通过检测不同版本 TiDB  的执行计划变化，帮助你识别性能退步的 SQL，在升级前识别执行计划变化带来的风险。\n- **Workload-sim** 通过使用 Database Replay 在测试系统上运行真实的工作负载，帮助你全面评估升级的效果。\n\n简单来说，TiDBA 是参数比对工具，提示你新增或修改的参数；pt-upgrade 主要解决的是兼容性和正确性问题；PCC 专门针对执行计划，解决潜在性能回退的问题；而 Workload-sim 是一份全量业务负载的拷贝，不仅可以提前发现升级潜在的问题，还可以评估升级的效果。他们所花费的资源由低到高，相应验证的效果也是从粗略到详细，你可以根据你的需求进行选择和自由组合。\n\n## 某乎的升级之旅\n接下来我们看看实战演练。案例中的 TiDB 用户是中文互联网高质量的问答社区和创作者聚集的原创内容平台，是中文最大的问答社区。选择升级的原因是旧集群版本较早，担心遇到修复的已知问题，造成运维事故；此外客户需要将所有业务统一到相同版本，方便统一运维管理。而待升级的集群承载其商广平台业务，是其最重要的商业集群之一，因此客户格外重视此次升级的安全保障。因此我们推荐客户采用 TiDBA + PCC + Workload-sim 的详尽策略，最终客户采用了 TiDBA 和 Workload-sim 对升级进行了测试验证。\n\n### 升级环境\n首先我们来看看集群的规模。\n\n#### 生产环境集群信息\n\n![1.png](https://img1.www.pingcap.com/prod/1_664a63147f.png)\n\n#### 测试环境集群信息\n\n![2.png](https://img1.www.pingcap.com/prod/2_7ad52ac650.png)\n\n**注意**：为了准确评估升级后风险，建议创建和生产环境规格类似的集群进行测试。\n\n### 升级流程\n然后我们来看具体的升级测试流程。\n\n![3.png](https://img1.www.pingcap.com/prod/3_63df2a2466.png)\n\n1. 使用 BR 从生产集群备份全量数据\n2. 使用 BR 将全量数据 restore 到测试集群\n3. 步骤 2 操作时，同时使用流量复制工具 workload-sim 在生产环境 v4.0.9 ，某一台 TiDB 节点采集流量（需要确认所有 TiDB 节点业务流量均衡访问）\n4. 步骤 2 完成，并且步骤 3 采集完成后，使用流量回放工具，在测试环境回放流量，收集信息\n5. 将测试集群从 v4.0.9 升级到 v4.0.14 目标版本，并且清空数据\n6. BR Restore 备份的全量数据（建议可以完全重建集群，不会有empty region 的影响）\n7. 使用流量回放工具在测试环境 v4.0.14 回放流量，收集信息\n8. 比对 v4.0.9 和 v4.0.14 版本的流量回放信息\n9. 4.0.9 生产和 4.0.14 的测试环境，使用 TiDBA 对比参数变化\n\n![4.png](https://img1.www.pingcap.com/prod/4_2e2699d1bd.png)\n\n### 升级比对\n接下来我们来看看流量回放效果的对比。\n\n#### 升级前\n\n![5.png](https://img1.www.pingcap.com/prod/5_015116cf78.png)\n\n#### 升级后\n\n![6.png](https://img1.www.pingcap.com/prod/6_41378a003b.png)\n\n从图中可以明显看出：升级前后，业务没有明显变化，因为是小版本的升级，是符合测试预期的。\n\n### 后记\n在完成升级测试工具的比对之后三天，客户在业务低谷期对生产环境进行了升级操作，而最终实际的升级也是同样的效果，整个过程相当平稳，业务基本没有感知。看到这里或许你会说，这结果看起来不是都一样嘛？是的，小版本的升级以及正确的升级操作大概率是能顺利收获新版本一枚。不同的是，**通过采用升级工具的验证比对，再进行升级操作，你知道升级是安全可预期的，所以你大可不必在升级选择面前患得患失，也不用在升级过程当中担心焦虑**。如果你还在忧虑纠结升级的苦与乐时，不妨来试试我们的升级工具，让他们来帮助你快乐升级！","date":"2022-01-10","author":"张粲宇，荣毅龙","fillInMethod":"writeDirectly","customUrl":"how-to-upgrade-tidb-happily","file":null,"relatedBlogs":[]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}