一、学习目标与全局认知1.1 学习目标理解传统主从、MHA、MGR 的定位与差异掌握故障切换流程、核心组件、常见配置与排错点面试回答优先说明解决什么问题、如何工作、边界是什么1.2 高可用架构概览一主一从基础复制故障通常手动切换一主多从读扩展、负载分担可配合 MHA主主复制双向复制需谨慎处理冲突与入口切换多主一从汇总多个源库数据级联复制 M-S-S-S减轻主库复制压力MHA在传统主从复制上提供故障切换MGRMySQL 原生组复制与自动选主1.3 组件职责边界主从复制数据冗余与读扩展MHA监控主库并执行故障切换MGR组内复制、成员管理、故障检测与选主Router / ProxySQL / HAProxy请求路由、读写分离或入口转发Keepalived VIP提供可漂移的访问入口自动选主不等于客户端连接自动恢复应用仍需重连二、MHA传统主从的高可用方案2.1 定义与组件MHA 是基于 MySQL 主从复制的故障切换软件Manager监控 master、协调切换可管理多组集群Node部署在数据节点辅助保存 binlog、应用差异 relay log典型拓扑一主两从具体节点数取决于部署设计2.2 主要能力与限制缩短主库故障后的中断时间尽可能抢救宕机主库尚未复制的 binlog降低数据丢失风险配合半同步复制可进一步降低丢数据风险切换时间与数据完整性受网络、日志状态、复制延迟和配置影响不要把固定耗时当作保证2.3 故障切换流程必背检测到 master 故障尽可能从故障 master 保存 binlog events比较从库复制进度选择数据较新的候选从库在其他从库应用差异 relay log应用从旧 master 抢救出的 binlog提升候选从库为新 master其他从库重新指向新 master恢复复制口诀抢救日志 → 补齐差异 → 选新主 → 其他从库跟随2.4 候选主库选择优先考虑复制位置 / GTID 进度更靠前、数据更完整的从库配置顺序可作为数据进度相同情况下的选择依据candidate_master 可标记候选主复制延迟相关参数会影响候选资格选主规则应以实际 MHA 版本与配置为准2.5 部署与验证流程准备环境主机名解析、时间同步、SSH 免密与网络连通先建立并验证一主两从复制server-id 唯一启用 binlog确认复制状态正常并按需配置从库 read_only安装 Node 及其依赖再安装 Manager配置应用集群配置文件、候选主与健康检查参数按部署方案配置 VIP / 故障切换脚本运行 masterha_check_ssh 与 masterha_check_repl 检查启动 Manager并验证监控、切换与恢复流程2.6 常用工具与参数masterha_check_ssh检查 SSH 免密与连通性masterha_check_repl检查复制状态masterha_check_status检查 Manager 状态masterha_master_monitor监控 mastermasterha_master_switch执行手动或受控切换masterha_stop停止 Managersave_binary_logs保存 binlogapply_diff_relay_logs应用差异中继日志purge_relay_logs清理中继日志ping_interval控制健康检查间隔remove_dead_master_conf切换后从配置移除故障主库ignore_last_failover影响连续故障切换限制避免反复切换2.7 切换后修复修复原 master 的 MySQL 服务并确认数据状态获取新主的复制坐标 / GTID 信息将原 master 配置为新主的从库并启动复制检查并恢复集群配置文件中的节点信息重新启动 Manager 并确认监控正常三、MGRMySQL Group Replication3.1 定义与关键概念MGR 是 MySQL 原生组复制方案MySQL 5.7 引入组成员通过组通信交换事务与成员状态Primary单主模式下的写节点Secondary单主模式下通常为只读节点可参与认证与应用事务GTID标识事务辅助追踪与判断事务执行情况事务认证Certification检测并发事务冲突Paxos / 组内协调帮助成员对事务顺序与结果达成一致多数派Quorum判断分区后哪一侧可以继续工作3.2 单主模式事务流程客户端将写请求发送到 Router 或应用配置的入口入口将写请求路由到当前 PRIMARY主节点执行事务并产生事务标识事务通过组通信传播到组成员成员进行认证与组内协调确定事务顺序和冲突结果通过认证的事务在各节点应用到 InnoDB事务提交响应受组复制确认机制影响各节点本地应用时点可能不同3.3 单主与多主单主一个节点负责写入其余节点通常只读结构清晰、冲突较少多主多个节点可写需考虑并发写冲突与业务约束模式选择要结合写入冲突、业务架构和运维复杂度3.4 多数派与脑裂多数派示例3 节点至少 2 个在线5 节点至少 3 个在线失去多数派时组可能无法继续正常处理事务脑裂网络分区后多个子集群都尝试独立提供写服务可能导致数据分歧多数派机制用于限制可继续工作的分区降低脑裂风险节点故障数与可用性取决于成员数量、故障类型和组状态3.5 主节点故障与路由恢复检测成员失联并更新成员视图判断剩余成员是否满足多数派条件满足条件时按组配置与选举规则选出新 PRIMARYRouter / 代理层刷新路由应用端可能仍需重连自动选主不代表业务请求完全无感3.6 MGR 与传统主从对比传统主从主从结构常见异步复制切换依赖人工或外部工具MGR组成员结构具备组内协调、成员管理与自动选主能力两者都需要关注复制延迟、网络、恢复流程与数据一致性MGR 不能替代 Router / ProxySQL 等路由组件3.7 部署核心要点通常以至少 3 个成员的拓扑更容易形成多数派容错配置唯一 server-id、GTID 与组复制相关参数常见参数包括 gtid_mode、enforce_gtid_consistency、binlog_formatROW、log_replica_updates旧版本常见 log_slave_updatestransaction_write_set_extraction、group_replication_group_name、local_address、group_seeds 等参数需按版本核对服务端口通常为 3306组通信端口需在成员间开放首个节点初始化组其他节点再加入严格按目标版本官方流程操作为恢复通道配置复制账号与权限不要把 RESET MASTER 当作通用排错步骤它可能清除关键日志 / GTID 信息执行前必须确认风险3.8 检查 SQL 与生产关注点查询 performance_schema.replication_group_members 查看成员与角色SHOW STATUS LIKE group_replication% 查看组复制状态STOP GROUP_REPLICATION 可停止本节点组复制按需设置 group_replication_start_on_boot可通过 group_replication_member_weight 影响选主优先级需核对版本网络不稳定时分析成员驱逐与超时配置不要只靠盲目调大参数备份可考虑在 Secondary 上执行但需评估负载、数据一致性与备份方案四、索引与事务面试基础补充4.1 索引基础索引用于帮助数据库更高效地定位数据但会增加存储与写入维护成本建索引应结合查询条件、排序、分组、选择性与执行计划判断不应仅凭表行数阈值决定是否建索引复合索引需理解最左前缀原则并通过 EXPLAIN 验证实际执行计划原始大纲仅提示索引面试题未展开完整索引类型与 SQL 细节4.2 事务基础ACID原子性、一致性、隔离性、持久性原子性事务中的操作作为整体提交或回滚一致性事务前后数据满足约束与业务规则隔离性并发事务之间按隔离级别控制可见性与冲突持久性提交后的结果在规定故障场景下可恢复原始大纲未展开隔离级别、锁与事务控制 SQL 的具体内容五、问答5.1 MHA 是什么基于传统主从复制的高可用故障切换工具Manager 负责监控协调Node 协助处理日志。5.2 MHA 切换的核心步骤保存故障主库 binlog → 补齐从库差异 → 选择较新的从库提升 → 其他从库跟随新主。5.3 MGR 与传统主从有什么区别MGR 具有组通信、事务认证、成员管理与自动选主能力传统主从通常依赖外部方案切换。5.4 为什么需要多数派网络分区时限制可继续工作的成员集合降低多个分区同时写入造成脑裂的风险。5.5 GTID 有什么作用标识并追踪事务辅助复制、恢复与判断事务是否执行。5.6 MGR 能替代 Router / ProxySQL 吗不能。MGR 负责组复制与选主路由、读写分离和客户端连接切换由代理层及应用配合完成。5.7 3 节点 MGR 能容忍几个节点失效在正常多数派规则下通常可容忍 1 个成员失效失去多数派后无法正常继续提交事务。5.8 MHA 与 MGR 如何选型MHA 适合已有传统主从架构并需要外部切换管理的场景MGR 是 MySQL 原生组复制方案需评估版本、网络与业务兼容性。 
长河君 · 2026/10/30 8:28:28 · 阅读 1.2k 5、MySQL 高可用实战：主从复制、MHA 与 MGR
一、学习目标与全局认知1.1 学习目标理解传统主从、MHA、MGR 的定位与差异掌握故障切换流程、核心组件、常见配置与排错点面试回答优先说明解决什么问题、如何工作、边界是什么1.2 高可用架构概览一主一从基础复制故障通常手动切换一主多从读扩展、负载分担可配合 MHA主主复制双向复制需谨慎处理冲突与入口切换多主一从汇总多个源库数据级联复制 M-S-S-S减轻主库复制压力MHA在传统主从复制上提供故障切换MGRMySQL 原生组复制与自动选主1.3 组件职责边界主从复制数据冗余与读扩展MHA监控主库并执行故障切换MGR组内复制、成员管理、故障检测与选主Router / ProxySQL / HAProxy请求路由、读写分离或入口转发Keepalived VIP提供可漂移的访问入口自动选主不等于客户端连接自动恢复应用仍需重连二、MHA传统主从的高可用方案2.1 定义与组件MHA 是基于 MySQL 主从复制的故障切换软件Manager监控 master、协调切换可管理多组集群Node部署在数据节点辅助保存 binlog、应用差异 relay log典型拓扑一主两从具体节点数取决于部署设计2.2 主要能力与限制缩短主库故障后的中断时间尽可能抢救宕机主库尚未复制的 binlog降低数据丢失风险配合半同步复制可进一步降低丢数据风险切换时间与数据完整性受网络、日志状态、复制延迟和配置影响不要把固定耗时当作保证2.3 故障切换流程必背检测到 master 故障尽可能从故障 master 保存 binlog events比较从库复制进度选择数据较新的候选从库在其他从库应用差异 relay log应用从旧 master 抢救出的 binlog提升候选从库为新 master其他从库重新指向新 master恢复复制口诀抢救日志 → 补齐差异 → 选新主 → 其他从库跟随2.4 候选主库选择优先考虑复制位置 / GTID 进度更靠前、数据更完整的从库配置顺序可作为数据进度相同情况下的选择依据candidate_master 可标记候选主复制延迟相关参数会影响候选资格选主规则应以实际 MHA 版本与配置为准2.5 部署与验证流程准备环境主机名解析、时间同步、SSH 免密与网络连通先建立并验证一主两从复制server-id 唯一启用 binlog确认复制状态正常并按需配置从库 read_only安装 Node 及其依赖再安装 Manager配置应用集群配置文件、候选主与健康检查参数按部署方案配置 VIP / 故障切换脚本运行 masterha_check_ssh 与 masterha_check_repl 检查启动 Manager并验证监控、切换与恢复流程2.6 常用工具与参数masterha_check_ssh检查 SSH 免密与连通性masterha_check_repl检查复制状态masterha_check_status检查 Manager 状态masterha_master_monitor监控 mastermasterha_master_switch执行手动或受控切换masterha_stop停止 Managersave_binary_logs保存 binlogapply_diff_relay_logs应用差异中继日志purge_relay_logs清理中继日志ping_interval控制健康检查间隔remove_dead_master_conf切换后从配置移除故障主库ignore_last_failover影响连续故障切换限制避免反复切换2.7 切换后修复修复原 master 的 MySQL 服务并确认数据状态获取新主的复制坐标 / GTID 信息将原 master 配置为新主的从库并启动复制检查并恢复集群配置文件中的节点信息重新启动 Manager 并确认监控正常三、MGRMySQL Group Replication3.1 定义与关键概念MGR 是 MySQL 原生组复制方案MySQL 5.7 引入组成员通过组通信交换事务与成员状态Primary单主模式下的写节点Secondary单主模式下通常为只读节点可参与认证与应用事务GTID标识事务辅助追踪与判断事务执行情况事务认证Certification检测并发事务冲突Paxos / 组内协调帮助成员对事务顺序与结果达成一致多数派Quorum判断分区后哪一侧可以继续工作3.2 单主模式事务流程客户端将写请求发送到 Router 或应用配置的入口入口将写请求路由到当前 PRIMARY主节点执行事务并产生事务标识事务通过组通信传播到组成员成员进行认证与组内协调确定事务顺序和冲突结果通过认证的事务在各节点应用到 InnoDB事务提交响应受组复制确认机制影响各节点本地应用时点可能不同3.3 单主与多主单主一个节点负责写入其余节点通常只读结构清晰、冲突较少多主多个节点可写需考虑并发写冲突与业务约束模式选择要结合写入冲突、业务架构和运维复杂度3.4 多数派与脑裂多数派示例3 节点至少 2 个在线5 节点至少 3 个在线失去多数派时组可能无法继续正常处理事务脑裂网络分区后多个子集群都尝试独立提供写服务可能导致数据分歧多数派机制用于限制可继续工作的分区降低脑裂风险节点故障数与可用性取决于成员数量、故障类型和组状态3.5 主节点故障与路由恢复检测成员失联并更新成员视图判断剩余成员是否满足多数派条件满足条件时按组配置与选举规则选出新 PRIMARYRouter / 代理层刷新路由应用端可能仍需重连自动选主不代表业务请求完全无感3.6 MGR 与传统主从对比传统主从主从结构常见异步复制切换依赖人工或外部工具MGR组成员结构具备组内协调、成员管理与自动选主能力两者都需要关注复制延迟、网络、恢复流程与数据一致性MGR 不能替代 Router / ProxySQL 等路由组件3.7 部署核心要点通常以至少 3 个成员的拓扑更容易形成多数派容错配置唯一 server-id、GTID 与组复制相关参数常见参数包括 gtid_mode、enforce_gtid_consistency、binlog_formatROW、log_replica_updates旧版本常见 log_slave_updatestransaction_write_set_extraction、group_replication_group_name、local_address、group_seeds 等参数需按版本核对服务端口通常为 3306组通信端口需在成员间开放首个节点初始化组其他节点再加入严格按目标版本官方流程操作为恢复通道配置复制账号与权限不要把 RESET MASTER 当作通用排错步骤它可能清除关键日志 / GTID 信息执行前必须确认风险3.8 检查 SQL 与生产关注点查询 performance_schema.replication_group_members 查看成员与角色SHOW STATUS LIKE group_replication% 查看组复制状态STOP GROUP_REPLICATION 可停止本节点组复制按需设置 group_replication_start_on_boot可通过 group_replication_member_weight 影响选主优先级需核对版本网络不稳定时分析成员驱逐与超时配置不要只靠盲目调大参数备份可考虑在 Secondary 上执行但需评估负载、数据一致性与备份方案四、索引与事务面试基础补充4.1 索引基础索引用于帮助数据库更高效地定位数据但会增加存储与写入维护成本建索引应结合查询条件、排序、分组、选择性与执行计划判断不应仅凭表行数阈值决定是否建索引复合索引需理解最左前缀原则并通过 EXPLAIN 验证实际执行计划原始大纲仅提示索引面试题未展开完整索引类型与 SQL 细节4.2 事务基础ACID原子性、一致性、隔离性、持久性原子性事务中的操作作为整体提交或回滚一致性事务前后数据满足约束与业务规则隔离性并发事务之间按隔离级别控制可见性与冲突持久性提交后的结果在规定故障场景下可恢复原始大纲未展开隔离级别、锁与事务控制 SQL 的具体内容五、问答5.1 MHA 是什么基于传统主从复制的高可用故障切换工具Manager 负责监控协调Node 协助处理日志。5.2 MHA 切换的核心步骤保存故障主库 binlog → 补齐从库差异 → 选择较新的从库提升 → 其他从库跟随新主。5.3 MGR 与传统主从有什么区别MGR 具有组通信、事务认证、成员管理与自动选主能力传统主从通常依赖外部方案切换。5.4 为什么需要多数派网络分区时限制可继续工作的成员集合降低多个分区同时写入造成脑裂的风险。5.5 GTID 有什么作用标识并追踪事务辅助复制、恢复与判断事务是否执行。5.6 MGR 能替代 Router / ProxySQL 吗不能。MGR 负责组复制与选主路由、读写分离和客户端连接切换由代理层及应用配合完成。5.7 3 节点 MGR 能容忍几个节点失效在正常多数派规则下通常可容忍 1 个成员失效失去多数派后无法正常继续提交事务。5.8 MHA 与 MGR 如何选型MHA 适合已有传统主从架构并需要外部切换管理的场景MGR 是 MySQL 原生组复制方案需评估版本、网络与业务兼容性。