1. 无停机升级全流程解密概览
1.1 定义与目标
在企业级应用场景中，无停机升级并非一个简单的口号，而是一套可落地的实现路径。本文围绕 平滑升级、不中断业务、以及数据一致性的保障展开，帮助工程师从理念到落地形成清晰的操作蓝图。
实现目标通常包括：业务可用性不下降、变更可控性提升、以及在升级过程中对潜在异常的快速响应能力。通过把升级拆解为准备、并行执行、切换与回滚等阶段，可以将风险降到最低。
要点在于以往的离线停机升级被替代为在线 DDL、数据复制的叠加变更，以及基于工具的变更迁移。此过程的关键在于确保在变更期间仍然能对外提供只读或半读写路径，从而实现真正的无停机体验。
SHOW SLAVE STATUS\G;1.2 关键阶段的里程碑
无停机升级通常划分为四大阶段：需求对齐、方案设计、执行与切换、以及一致性验证与回滚准备。每个阶段都应设定可度量的里程碑和回退条件，以确保在遇到异常时能够快速回到稳定点。
在设计阶段，要明确不同方案对业务路径、数据模型、以及运维工作量的影响。对于大型系统，通常需要结合复制滚动、蓝绿切换或在线 DDL 的组合方案来实现无停机升级的目标。
为了确保团队成员对流程有一致认知，建议在正式上线前进行多轮演练，覆盖正常路径、异常路径与回滚路径的全流程。
# 演练脚本示例：验证升级路径的可用性
echo "Starting dry-run upgrade..."
./upgrade-dry-run.sh --target-version 8.0.XX --database prod --table transactions
2. 方案与准备：对比与选型
2.1 方案对比要点
在 MySQL 环境中，常见的无停机升级方案包括滚动升级、蓝绿升级、以及利用在线 DDL 工具如 gh-ost、pt-online-schema-change 的变更迁移。滚动升级通过逐台从库应用升级并维持主库对外提供服务的方式实现无停机；蓝绿升级则创建一个并行的新集群，完成变更后再进行路由切换；在线 DDL 工具则在不锁表的前提下完成结构变更，降低停机风险。
选择时要评估以下维度：数据量规模、可用性要求、变更类型（DDL 的复杂度、数据迁移量）、以及运维能力与工具生态。
为不同场景提供灵活性，通常会把方案混合使用：例如在从库做滚动升级，同时对新结构使用 gh-ost 进行在线 DDL，随后对主从路由进行短时灰度切换。
# gh-ost 在线变更示例（添加列）
gh-ost --host=db-slave-01 --user=root --password=****** \--database=mydb --table=orders --alter="ADD COLUMN retry_count INT NOT NULL DEFAULT 0" \--critical-load=Threads_running=8 --chunk-size=1000 --chunk-time=0 --allow-on-master=false
2.2 场景制订与容量评估
在准备阶段，应完成容量评估、并行度设定、以及对异常的回退策略设定。容量预算需要覆盖峰值并发、数据迁移时的 I/O 带宽，以及网络抖动带来的潜在影响；回退窗口应确保在任意阶段都能回到稳定点。
对于长期演练，建议建立一个“仿真环境”来重复执行完整的无停机升级流程，确保在正式升级时能快速应对不可预见的问题。
3. 在线无损升级实现路径
3.1 滚动升级核心步骤
滚动升级的核心在于把升级工作分散到从库，主库保持对外只读或可用状态，并在不影响写入路径的前提下完成变更。逐台升级不仅降低了单点风险，也让回滚变得更简单。
实现时，需要对主从延迟、二级索引重建时间、以及 DDL 的执行影响进行监控，确保新版本在从库达到一致性后再逐步切换到主库。切换策略通常采用短时停留的灰度路由，避免对现有业务路径造成冲击。
下面给出一个滚动升级的示例流程，便于理解执行顺序与变更点的关系。
# 从库逐台升级示例（伪代码，实际执行需结合运维脚本）
for host in db-slave-01 db-slave-02 db-slave-03; dossh $host "sudo apt-get update && sudo apt-get install mysql-server-8.0"ssh $host "systemctl restart mysqld"ssh $host "mysql -u root -p'pwd' -e 'SHOW VARIABLES LIKE \"innodb_version\";'"
done
3.2 在线 DDL 工具的应用与注意点
在需要对大表进行结构变更时，使用在线 DDL 工具（如 gh-ost、pt-online-schema-change）可以将锁表时间降至最短。变更粒度与监控粒度要精细化设置，避免对生产热路径造成冲击。
示例场景包括：添加列、修改列类型、建立新的索引等。通过工具实现“增量切换、逐步应用、逐步验证”的模式，确保在变更过程中的可观测性。
# pt-online-schema-change 示例
pt-online-schema-change --user root --password 'pwd' --host db-slave-01 \--alter "ADD COLUMN last_login TIMESTAMP NULL" D=mydb,t=users --execute
3.3 数据同步与路由调整
在升级过程中，数据的一致性检查与路由调整同样重要。数据同步要确保新版本对现存数据结构的写入和读取在多个副本间保持一致；路由调整需要在短时间内完成，并通过健康检查和灰度策略逐步放大流量。
实践中，可以通过将新版本的实例先以只读或低 QPS 的方式接入流量，然后在验证通过后逐步提升权重，最终完成全量切换。
CHECKSUM TABLE orders;pt-table-checksum --host db-master --database mydb --tables orders4. 数据一致性与回滚策略
4.1 一致性保障方法
数据一致性是无停机升级的核心保障。CHECKSUM 机制、增量捕获日志和主从对比校验共同保障数据在变更过程中的一致性。
常见做法包括：在变更前后进行全量与增量对比、通过 pt-table-checksum/p t-table-sync 进行跨副本对齐，以及在变更阶段对关键业务数据进行快照比对。
pt-table-checksum --replicate-check-only --host db-master --database mydb --tables orders4.2 回滚与容错流程
在任何阶段都应明确回滚路径，以应对不可预期的异常。回滚策略通常包括：降级回主后路由、回滚变更脚本、以及在必要时使用备用从库重新切换。
为确保回滚的可执行性，应在演练中验证回滚脚本的可用性并确保数据能快速回到稳定状态。
# 简化回滚示例：重新建立主从
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='old-master', MASTER_USER='repl', MASTER_PASSWORD='pwd';
START SLAVE;
5. 监控、运维与演练要点
5.1 监控指标与告警
在无停机升级期间，监控是评估健康状况的第一线。需要关注的核心指标包括：复制延迟、锁等待时间、DDL 阻塞时长、以及 主从一致性差异等。通过仪表板和告警规则，能在异常发生时快速定位并采取措施。
同时，应该对变更过程中的关键事件进行日志留存，确保可追溯性和事后分析能力。
SHOW SLAVE STATUS\G;tail -f /var/log/mysql/error.log5.2 演练与落地计划
无停机升级的落地需要有完整的演练计划：包含演练覆盖范围、角色分工、回滚条件和变更日志。通过定期演练，可以显著提高对异常路径的识别能力，并确保正式执行时的流畅与可控。
演练过程中要复现生产环境的高并发场景，验证滚动或蓝绿切换的可用性，以及在线 DDL 的锁定影响是否在可接受范围内。
