MySQL 新技术系列第四期

📢 MySQL 新技术系列第四期

各位数据库同行、开发者朋友们，大家好！

欢迎回到「MySQL 新技术」系列。在前三期，我们依次全景解读了 9.x 版本策略、向量检索技术，以及 JavaScript 存储程序与多语言引擎。这些话题分别聚焦于 AI-Ready 数据平台和开发范式变革，而本期我们将回归数据库运维最核心的命题——高可用。

在传统的主从复制时代，故障切换要么依赖人工介入，要么借助外部组件（如 MHA、Orchestrator），不仅运维成本高，而且恢复时间难以保证。随着 MySQL 9.3 引入智能主节点选举，再到 9.7 LTS 将企业级高可用能力开放至社区版，MySQL Group Replication 正在经历从「被动容错」到「主动智能恢复」的质变。

本期将系统梳理 Group Replication 在 9.x 系列中的技术演进，解读智能选举、自动重加入、多线程应用器增强等核心特性，并结合 Uber 大规模迁移的真实案例，探讨新一代高可用架构的最佳实践。

一、Group Replication 架构回顾：从基础到演进

1.1 什么是 Group Replication？

MySQL Group Replication 是一种基于 Paxos 共识协议的分布式状态机复制方案，通过组通信系统（Group Communication System，GCS）在集群成员之间传播事务，确保数据在多数节点上达成一致后才正式提交。相比传统的异步复制或半同步复制，Group Replication 提供了更高的数据一致性保障和内置的故障自动切换能力。

1.2 两种运行模式

模式	说明	适用场景
单主模式	仅一个节点（Primary）接受写操作，其余节点（Secondary）为只读	绝大多数生产场景，简化写入冲突处理
多主模式	所有节点均可接受写操作，通过冲突检测机制防止数据不一致	对写入可用性要求极高的场景，但需要应用层处理分布式事务冲突

在单主模式下，当主节点发生故障时，集群会自动触发选举流程，选出一个新的主节点，客户端写入请求可以迅速恢复。这一「自动化」正是 Group Replication 区别于传统主从复制的核心优势。

1.3 9.x 系列演进路线图

版本	Group Replication 关键演进
9.0	基础能力持续优化
9.1	原子 DDL（CREATE/DROP DATABASE）实现崩溃安全
9.2	复制监控与性能调优
9.3	Up-to-date Aware Primary Election（企业版首发）；自动重入组（Auto-Rejoin）增强
9.4-9.6	增量优化与稳定性提升
9.7 LTS	智能选举能力开放至社区版；Flow-control monitoring 开放；自动驱逐与重加入开放

二、🔄 智能主节点选举：从「权重优先」到「数据优先」

2.1 传统选举算法的局限性

在 9.3 之前的版本中，Group Replication 的主节点选举主要依赖 成员权重（member weight） 机制：DBA 为每个成员配置一个权重值，选举时权重最高的节点胜出；如果权重相同，则以 server_uuid 的字典序作为决胜依据。

这套机制虽然简单可控，但存在一个明显的盲点——权重反映的是管理员的偏好，而非节点实际的数据状态。设想一个场景：某从节点由于网络波动或硬件瓶颈而出现了较大的数据延迟，但管理员仍为其配置了较高的权重。当主节点发生故障时，这个「延迟节点」可能被选为新的主节点，然后不得不花费相当长的时间追赶缺失的事务日志，从而大幅延长故障恢复时间。

2.2 Up-to-date Aware Primary Election（9.3）

为解决这一痛点，MySQL 9.3 引入了一种新的选举策略：Most Up-to-date（数据最新优先）。该策略在执行权重比较之前，会先检查各成员的数据状态，选择数据最新的节点作为主节点，从而显著减少故障转移后的同步时间。

该功能通过组件 component_group_replication_elect_prefers_most_updated 实现。DBA 需要在所有组成员上安装该组件：

INSTALL COMPONENT 'file://component_group_replication_elect_prefers_most_updated';

启用后，选举流程变为多级判定：

Step 1：比较各成员的数据最新程度（基于事务序列号等指标），选择数据最新的节点 → Step 2：若数据最新程度相同，再比较成员权重 → Step 3：若权重也相同，按 server_uuid 字典序决胜。

为了便于监控和排查，该组件还提供了状态变量：

状态变量	说明
`Gr_latest_primary_election_by_most_uptodate_members_trx_delta`	新主节点与第二最新节点之间的事务差距数量
`Gr_latest_primary_election_by_most_uptodate_member_timestamp`	最后一次使用「数据最新优先」策略进行选举的时间戳

当使用该策略选举出新主节点时，MySQL 还会记录一条日志，明确说明选举依据和新主节点与次新节点之间的事务差距，为故障复盘提供了清晰的可追溯性。

2.3 从企业版到社区版（9.7 LTS）

在 9.3 版本中，该功能仅限 MySQL 企业版用户使用。随着 9.7 LTS 的发布，Oracle 兑现了将企业级能力开放至社区版的承诺——Up-to-date Aware Primary Election 现已面向所有 MySQL 用户免费开放。这意味着即使是社区版用户，也能在生产环境中享受这一智能故障恢复能力。

三、⛑️ 自动恢复：从手动介入到智能自愈

3.1 自动重加入（Auto-Rejoin）

在分布式环境中，节点被「驱逐」的原因多种多样：网络短暂中断、硬件抖动、资源争抢等，其中相当一部分是临时性故障，节点在条件恢复后本应自动回归集群。但在早期版本中，被驱逐的节点只能被动地进入只读模式，等待管理员手动介入。

MySQL 9.3 在自动恢复方面做出了重要改进。当节点被驱逐后，它会自动尝试重新加入集群，每次尝试间隔 5 分钟，最多尝试 3 次。如果所有尝试均失败，节点才进入只读模式等待人工介入。

该行为可通过变量 group_replication_autorejoin_tries 进行配置：

SET GLOBAL group_replication_autorejoin_tries = 5;  -- 最多尝试5次

在 InnoDB Cluster / AdminAPI 层面，也可以通过 autoRejoinTries 选项在集群级别或实例级别进行配置，接受 0 到 2016 之间的整数，默认值为 3。

⚠️ 重要提示：自动重加入机制要求被驱逐的节点在重试期间始终保持只读模式，以避免在重连过程中产生数据冲突。若集群已失去法定人数（Quorum），则不应期望成员自动重加入，因为法定人数是重新加入的前提条件。

3.2 自动驱逐与重加入（Automatic Eviction & Rejoin）

9.7 LTS 进一步强化了集群的韧性。新增的 Automatic Eviction & Rejoin 能力使集群能够自动检测不健康成员、驱逐不稳定节点，并在条件恢复后自动重新加入。这一能力与前述的 Up-to-date Aware Primary Election 共同构成了更完整的智能自愈闭环。

3.3 退出状态动作（exitStateAction）

group_replication_exit_state_action 变量定义了节点意外退出集群时的行为，可选值包括：

值	说明
`READ_ONLY`	节点变为只读模式（默认）
`OFFLINE_MODE`	节点断开现有客户端连接，仅接受管理员连接
`ABORT_SERVER`	MySQL 服务直接关闭，需手动重启

需要特别注意的是，当使用自动重加入功能时，exitStateAction 配置的动作仅在所有重加入尝试均失败之后才会执行。

四、📊 可观测性增强：让复制状态清晰可见

4.1 流量控制监控（Flow-control Monitoring）

在 9.7 LTS 之前，当 Group Replication 启用流量控制（Flow Control）时，DBA 只能看到集群被节流，却无法获知节流的严重程度以及其对整体吞吐量造成的影响。9.7 LTS 将流量控制监控能力开放至社区版，使 DBA 能够清晰了解集群何时被节流、节流效果如何。

4.2 多线程应用器扩展统计（Multi-threaded Applier Extended Statistics）

在多线程复制场景中，应用器（Applier）的工作状态直接决定了从节点的数据同步效率。9.7 LTS 在社区版中引入了扩展统计信息，帮助 DBA 更精准地监控延迟、吞吐量、队列积压以及工作线程的行为。

该特性与 GTID 复制架构的优化相辅相成——9.6 版本引入了全新的 GTID 集合数据结构库，替换了旧有实现，使全局事务 ID 的处理逻辑更简洁、性能更高效，进一步增强了分布式环境下数据一致性的保障能力。

4.3 OpenTelemetry 集成

9.7 LTS 还引入了对 OpenTelemetry / OTLP 协议的支持，支持将日志、指标和链路追踪数据导出至主流可观测性平台（如 Prometheus、Jaeger），使 MySQL 能够无缝融入现代化运维监控体系。对于 SRE 团队而言，这意味着可以在同一个观测平台上统一管理数据库节点与应用服务的可观测数据，降低了运维工具链的碎片化程度。

五、多源复制：从基础到新范式

5.1 多源复制基础回顾

多源复制（Multi-Source Replication）允许一个从库从多个不同的主库并行接收事务。在多源复制拓扑中，从库会为每个主库创建一个独立的复制通道（replication channel）。

典型应用场景包括：

将多个服务器的数据备份到单个服务器
合并多个数据库分片（Table Shards）
将多个业务系统的数据汇聚到统一的分析节点

需要特别注意的是，每个通道必须从不同的源进行复制。同一个从库不能为同一个主库创建多个复制通道，因为 MySQL 仅通过 server_id 区分客户端，无法识别通道名称。

5.2 异步连接故障转移（Asynchronous Connection Failover，9.6）

9.6 版本引入了一个在多源复制场景中极为实用的特性——异步连接故障转移。

该机制允许从库维护一个主库候选列表（Source List），当当前连接的主库发生故障时，系统会根据预先配置的加权优先级自动从列表中选择一个新的主库建立连接。

更值得一提的是，该机制原生支持 Group Replication 拓扑：当在源列表中加入一个组成员并将其定义为托管组（Managed Group）时，系统会自动监控组成员变化，在成员加入或离开时自动增删源列表中的条目。只有处于在线状态且属于多数组的成员才会被用于连接和获取状态。

使用前提：

必须在源端和从端启用 GTID（gtid_mode=ON）
必须启用 SOURCE_AUTO_POSITION 选项
源列表中的所有主库必须使用相同的复制用户账号和密码
该复制用户需具备 Performance Schema 表的 SELECT 权限

-- 配置异步连接故障转移的示例
CHANGE REPLICATION SOURCE TO 
    SOURCE_HOST='primary1.example.com',
    SOURCE_USER='repl_user',
    SOURCE_PASSWORD='xxx'
FOR CHANNEL 'channel1';

-- 配置候选源列表
CHANGE REPLICATION SOURCE TO 
    SOURCE_CONNECTION_AUTO_FAILOVER=1,
    SOURCE_LIST='primary1.example.com:3306,primary2.example.com:3306'
FOR CHANNEL 'channel1';

5.3 复制过滤器增强（9.6）

9.6 版本还为多源复制提供了通道级别的复制过滤器。当同一个数据库或表存在于多个源上时，DBA 可以通过通道特定过滤器精确控制从哪个源复制该数据，避免数据重复或冲突。

六、滚动升级与版本兼容性

6.1 兼容性策略

MySQL Group Replication 支持在升级过程中在同一组内安全地混合运行不同版本的成员，这为滚动升级提供了可能性。但需要注意：

新版本成员加入旧版本组时，只能以只读从节点身份运行（super_read_only=ON）
主节点只能由组内最低版本的成员担任
组内不允许出现两个以上不同的 MySQL 主版本
MySQL 官方不支持 Group Replication 跨大版本混跑（例如 5.7 和 8.0 无法组成同一 group）

6.2 滚动升级方法

滚动升级（Rolling In-Group Upgrade）的核心流程：

将目标成员从组中移除
执行就地升级（in-place upgrade）或逻辑升级
将升级后的成员重新加入组（以只读模式）
重复以上步骤升级其他成员
待所有成员升级完成后，组自动恢复读写模式（8.0.17 及以上版本）

若需要保持特定节点为主节点，应将该节点安排在最后进行升级。升级完成后，可使用 group_replication_set_as_primary() 函数将其重新指定为主节点。

对于多主模式组，滚动升级期间写可用性会下降，因为升级中的节点在重新加入后只能以只读模式运行。

七、案例研究：Uber 大规模迁移至 Group Replication

7.1 迁移背景

在 2025 年底至 2026 年初，Uber 完成了将数千个 MySQL 集群从基于 Orchestrator 的复制架构迁移到 MySQL Group Replication 的规模化工程。这一迁移并非简单的版本升级，而是一次从根本上重塑高可用架构的深度改造。

7.2 迁移动机

Uber 原有架构的核心痛点是故障转移时间不可控。在 Orchestrator 方案中，故障恢复涉及多个外部组件（Consul、Orchestrator、VIP 漂移等）的协同，每个环节都可能引入额外延迟。而当新主库处于滞后状态时，故障恢复时间会被进一步拉长。

Group Replication 的内置选举机制和 Paxos 共识协议，将故障检测、主库选举、客户端重路由整合为一个原子化流程，故障转移时间从分钟级大幅缩短至秒级。

7.3 关键经验

Uber 在迁移过程中积累的实践经验包括：

一致性优先于性能：Group Replication 的多副本强一致模型虽然带来一定的写入延迟，但显著提升了数据安全性和故障恢复的可预测性
渐进式迁移：优先将非核心业务集群迁移至 Group Replication，积累运维经验后再逐步扩大范围
监控与告警升级：建立针对 Group Replication 组视图变化、选举事件、流控触发的精细化告警体系

Uber 的成功案例表明，即使是在超大规模场景下，Group Replication 也能作为 MySQL 高可用的可靠基石，支撑起企业级的生产负载。

八、生产环境最佳实践

8.1 部署配置建议

配置项	推荐值	说明
集群规模	3 或 5 个节点	确保故障时仍能维持多数派
`group_replication_autorejoin_tries`	3~5	根据网络稳定性调整
`group_replication_member_expel_timeout`	5~10 秒	平衡故障检测速度与误判风险
`group_replication_flow_control_mode`	`QUOTA`	推荐使用配额模式进行流控
`group_replication_communication_debug_options`	谨慎启用	生产环境建议关闭，仅调试时开启

8.2 智能选举策略选择

在 9.7 LTS 之后，社区版用户可以选择两种选举策略的组合使用：

仅使用权重策略：适用于管理员对节点角色有明确偏好的场景（如指定某地域节点优先成为主库）
启用数据最新优先策略：适用于数据一致性要求极高的场景，可以最大限度减少故障转移后的数据追赶时间
两者结合：该组件在执行「数据最新优先」判定之后仍会使用权重作为第二级判定依据，可以实现「数据优先下的偏好控制」

8.3 故障演练清单

在生产环境启用 Group Replication 前，建议完成以下故障场景的演练：

[ ] 主库节点进程异常终止，验证选举流程和新主库切换时间
[ ] 网络分区场景，验证多数派与少数派节点的行为差异
[ ] 延迟节点加入场景，验证自动重加入机制与数据同步流程
[ ] 滚动升级场景，验证版本兼容性与业务无感知程度
[ ] 多源复制主库故障场景，验证异步连接故障转移的生效情况

8.4 注意事项

法定人数（Quorum）不可丢失：如果集群失去多数派，将无法进行新的主库选举，需通过手工恢复或 group_replication_force_members 强制重建组（仅在应急场景使用）
跨版本升级的只读限制：升级过程中新版本节点只能以只读方式运行，需确保业务可接受临时的写入可用性下降
网络延迟敏感：Group Replication 对节点间网络延迟较为敏感，建议部署在同一数据中心或延迟可控的区域内

九、展望

随着 9.7 LTS 将 Up-to-date Aware Primary Election、Flow-control Monitoring、Automatic Eviction & Rejoin 等高可用特性开放至社区版，MySQL Group Replication 的可落地性和可运维性得到了质的提升。展望未来的 10.x 创新版，值得期待的方向包括：

更智能的流量控制：基于机器学习预测集群负载，动态调整流控阈值
跨区域部署增强：优化广域网环境下的组通信协议，降低跨地域部署的延迟
与 OpenTelemetry 的更深度融合：实现更细粒度的可观测性数据采集
多源复制的冲突检测：引入更智能的冲突解决策略，降低应用层负担

十、总结

本期我们系统解读了 MySQL 9.x 系列在 Group Replication 与多源复制领域的技术演进：

Up-to-date Aware Primary Election 从根本上改变了传统选举策略「重权重、轻数据」的局限性，使故障恢复时间显著缩短
自动重加入（Auto-Rejoin） 与 自动驱逐与重加入（Automatic Eviction & Rejoin） 构成了集群的智能自愈闭环
可观测性增强（Flow-control monitoring、扩展统计、OpenTelemetry）使 DBA 能够清晰了解复制状态的每一个细节
多源复制 通过异步连接故障转移、通道级过滤器等特性，在数据汇聚和容灾场景中释放了更大的灵活性
Uber 的大规模迁移案例 证明了 Group Replication 在超大规模生产场景中的可行性和可靠性
9.7 LTS 将上述多项企业级能力开放至社区版，使更广泛的用户群体能够受益于 MySQL 高可用技术的最新成果

如果说前几期的向量检索和 JavaScript 存储程序代表了 MySQL 在「AI 与开发范式」方向上的突破，那么本期所聚焦的高可用技术演进，则代表着 MySQL 在「基础架构韧性」这一核心能力上的持续深耕。

下一期预告：MySQL 新技术系列第五期——「MySQL 9.x 安全加固：从 OpenID Connect 到动态数据脱敏」。我们将系统梳理 9.x 系列在身份认证、权限管理、数据加密、审计与脱敏等方面的安全增强，并提供面向企业级合规场景的安全配置最佳实践。敬请期待！

欢迎大家在评论区留言交流，告诉我你最想深入了解的主题，我会在后续系列中优先安排！

📚 参考资料

Oracle Blog: Improve Primary Selection on Failover in MySQL Group Replication
MySQL Worklog WL#16432: GR: Up-to-date Aware Primary Election on Failover
Oracle Blog: MySQL 9.7.0 LTS Is Now Available: Expanded Community Capabilities and Dynamic Data Masking for Enterprise
MySQL 9.6 Reference Manual: 19.1.5 MySQL Multi-Source Replication
MySQL 9.6 Reference Manual: 19.4.9 Switching Sources and Replicas with Asynchronous Connection Failover
MySQL 9.3 Reference Manual: 20.7.7 Responses to Failure Detection and Network Partitioning
MySQL Shell 9.3: Configuring Automatic Rejoin of Instances
MySQL 8.0 Reference Manual: 20.8.3.3 Group Replication Online Upgrade Methods
掘金: MySQL 9.6.0 创新版正式发布：现代化数据库架构新突破
Uber Engineering Blog: Improving MySQL Cluster Uptime: Making MGR Viable at Scale
技术栈网: MySQL Group Replication（MGR）核心机制解析