Github 花了一年多的时间，将他们的 1200 台 MySQL 集群从 v5.6 升级到了 v8.0，这里的难度非常之大，没做过大规模集群服务器运维的难以理解此中的难度、难以理解其中庞大的业务量，难以想象升级过程中的海量问题的解决等等。
Github 的运维做了非常多的工作，整个过程集群升级有值得借鉴的东西。
过去几年，我做过Gentoo服务器的运维和安全防护工作。平时在单位也兼顾作137台计算机的运维，平均在线量也有58台/天，当然这个QPS（TPS）没法和 Github 这个规模比较，Github 的 QPS 达到了 550w，极其恐怖。
Github 采用的是分库分表的设计，在数据库调用这一层上，做的相对比较复杂，架构的复杂自然也带来了工具和工程的复杂度，从而增加了大量的运维成本。尤其是集群操作上，如何借鉴单机操作的思路和容灾模式，对集群进行滚动，如何多版本共存等，都是超级值得借鉴的。
在Gentoo服务器上，早先几年就开始出现沟道处理技术。沟道处理技术是一种容灾机制，随着硬盘容量的提升，可以在服务器上建立多个（至少2个）沟道（slot）,先将系统的内核等埋在slot A 上，当滚动更新时，一旦滚动更新出现问题，也无法回滚，那么在Slot B保持现有问题系统，回滚slot A 进行复位回滚。这说起来简单，实际操作中经常遇到slot conflict。注意现在安卓手机13、14的系统上也使用了沟道技术。
Github 将自己的升级工作共享了，这篇文章提到了一些对抗软件复杂度的方法和细节，包括集群的脚本升级策略降低重复工作，提高效率；低回滚机制的设计；混合版本提供服务等，肯定有Gentoo或者Arch的资深玩家，很多系统上的技术直接用到了集群操作上，格局一下打开了。
只不过对细节的描述偏少，只是宏观的蓝图，所以可实际操作的太少，只能原理性的借鉴学习。很多东西不会简单的共享出来，我懂，真是太遗憾了。
github升级思路公开的地址：https://github.blog/2023-12-07-upgrading-github-com-to-mysql-8-0/