Uber今年将MySQL 5.7升级到v8.0，可以说非常有实际参考价值，没有太多的银弹，要的是安全可靠的升级策略。
为什么要升级到MySQL v8.0
1：MySQL v5.7已经到了它的生命周期（2023/10），后续可能会存在一些安全或Bug问题。
2：提升性能，MySQL v8.0在索引和并行执行方面有了很大的改进。
3：MySQL v8.0有一些新的功能，比如窗口函数，增强的JSON处理等。
4：MySQL v8.0引入的“双密码”功能，这对于维护非常有效。
5：MySQL v8.0的Instant ADDColumn可以不用在锁表或停机的情况下增加字段，减少对线上的影响。
uber的MySQL架构
1：规模非常大，超过2100个集群，有19个zones，分布在3个regions，超过16,000个节点。
2：数据量达到PB级别，每秒处理300万个查询。
3：集群架构，每个MySQL集群的MySQL实例分布在不同的节点上，确保了高可用性和容错能力。
4：主从复制，主节点复制写，从节点异步复制数据，确保了冗余和容错，在主节点挂的时候能够无缝切换。
MySQL升级过程中的挑战
Uber的MySQL基础设施规模庞大，拥有超过2,100个集群和16,000多个节点，分布在各个区域和地区，这给我们带来了重大挑战。手动升级显然不是一个可行的选择。为了应对这一问题，我们制定了一项全面的多步骤升级策略，并行升级(Side-by-Side Upgrade)，该策略可以在不同环境中高效执行，需要精心协调；最后就是减少人工干预，人工操作越多风险就越大，也说明策略不完美。
对于升级方案来说，一定要是可扩展的，扩展无处不在。
决定升级策略的一个关键因素：
MySQL v5.7主节点同步到MySQL v8.0是可以的，反过来是不行的
升级步骤
并行升级，v8.0版本的MySQL与现有版本v5.7并行安装，在单独的服务器上部署和配置新版本，一旦新服务器准备就绪，流量将逐步重定向到新版本，从而实现平稳过渡。
从高层次看，升级过程如下图：
• 节点复制，添加v8.0副本节点，与v5.7一起运行
• 监控v8.0同步情况
• 将浏览逐步从v5.7切走
• v8.0变更为主节点
• 稳定后删除所有v5.7节点
从更高层次分四个阶段，直接看图即可。
1：预维护阶段
2：系统监控
3：维护阶段
4：后维护阶段
回滚策略
在升级的每一阶段都需要回滚策略，一旦观察到某个步骤存在问题需要及时回滚，优先考虑最小化风险并确保数据完整性，所以操作都要是可逆的，不能丢失数据。
简单的说，在预维护阶段立刻删除v8.0节点，就可以回滚，但需要注意的是一旦v8.0节点被提升为主节点，对v5.7节点的复制就会停止，这一转变标志着与v5.7兼容性的不可逆点。
也就是说这个时候已经没法回滚了，否则就会数据丢失，所以在前面的步骤必须没有问题，最好在线上多运行一段时间。
遇到的问题
1：v8.0版本某些查询的执行计划发生变化，导致延迟增加资源消耗，后来Percona提供了一个补丁解决，确保性能和效率和v5.7的时候一样。
2：某些配置和查询不支持，比如某个集群没有启用“STRICT_TRANS_TABLES”SQL模式，但v8.0默认是开启的，导致出现问题，“ONLY_FULL_GROUP_BY”SQL模式也是类似的问题。
3：排序规则的变更，v5.7版本使用的是utf8mb4_unicode_520_ci，而它不支持v8.0的规则utf8mb4>utf8mb4_0900_ai_ci排序规则。
4：客户端不兼容，许多现有的客户端库与MySQL v8.0不兼容，所以在升级v8.0之前先要升级这些库。
升级带来的收益
1：服务器端性能
使用1024个线程100万次插入操作，P99延迟降低29%：
使用1024个线程100万次读操作，P99延迟降低33%：
2：客户端性能提升
数据库整体锁定时间减少94%：
某些查询时间减少78%：
整个过程结束，话说我也在线无缝升级v5.6版本到v5.7版本，整个思路是一样的，只是数据量级和重要性差的太多了，几个体会吧，大规模系统升级一定要有完善的自动化方案；要有充分的观察期和回滚机制；分批次、分阶段进行更为稳妥；提前识别和解决兼容性问题很重要；减少人工操作。
