《MySQL高可用面试核心考点问答清单》

一、基础概念与高可用概述

Q1：什么是高可用？MySQL高可用的核心目标是什么？

答：高可用是指系统无中断提供服务的能力，计算公式为：可用性=正常运行时间/(正常运行时间+故障时间)。

MySQL高可用的核心目标：

• 数据不丢失（数据持久性）
• 服务不中断（业务连续性）
• 故障自动恢复（减少人工干预）
• 读写分离扩展（提升系统吞吐量）

Q2：解释"三个九"、"四个九"、"五个九"分别代表什么？

答：

• 99.9%（三个九）：年停机时间≤8.76小时，适用于非核心业务
• 99.99%（四个九）：年停机时间≤52.56分钟，适用于大多数核心业务
• 99.999%（五个九）：年停机时间≤5.26分钟，适用于金融、电信等对可用性要求极高的业务

Q3：MySQL高可用技术的演进路线是怎样的？

答：异步主从复制 → 半同步复制 → 增强半同步复制 → MySQL Group Replication(MGR)

二、主从复制原理

Q4：MySQL主从复制的核心作用有哪些？

答：

1. 高可用：主库故障时，从库可提升为主库
2. 读写分离：写操作主库，读操作从库，提升系统吞吐量
3. 数据备份：从库执行备份，不影响主库性能
4. 数据分析：从库运行复杂查询，隔离业务压力

Q5：主从复制的三个核心线程分别是什么？各自的职责是什么？

答：

Q6：详细描述主从复制的完整执行流程。

答：

1. 从库执行CHANGE MASTER TO命令，配置主库连接信息
2. 从库IO线程向主库发起连接请求，携带从库已复制到的binlog位置
3. 主库验证身份后，启动Binlog Dump线程
4. Binlog Dump线程从指定位置开始，读取主库binlog事件，发送给从库IO线程
5. 从库IO线程接收binlog事件，写入本地relay log文件，并更新master.info
6. 从库SQL线程检测到relay log有新内容，读取并解析事件
7. SQL线程在从库执行这些事件，完成数据复制
8. SQL线程更新relay-log.info文件，记录已执行的relay log位置

Q7：主从复制有哪三种模式？各自的优缺点是什么？推荐使用哪种？

答：

1. 基于语句的复制（SBR）：复制主库执行的SQL语句
   • 优点：binlog体积小，节省磁盘和网络IO
   • 缺点：存在数据不一致风险（如NOW()、RAND()、存储过程）
2. 基于行的复制（RBR）：复制行数据的变化
   • 优点：数据一致性高，几乎没有不一致的情况
   • 缺点：binlog体积大，网络传输和重放开销大
3. 混合模式复制（MBR）：自动在SBR和RBR之间切换
   • 优点：兼顾性能和一致性
   • 缺点：切换逻辑复杂，仍有一定不一致风险

推荐：MySQL 5.7及以上版本使用RBR模式，数据一致性最高。

Q8：什么是GTID？GTID复制相比传统复制有哪些优势？

答：GTID（全局事务标识）是一个唯一的标识符，用于标识一个已经提交的事务。

GTID复制的优势：

1. 简化主从切换：无需手动指定binlog文件名和位置
2. 自动跳过已执行事务：避免重复执行导致的数据不一致
3. 更可靠的故障恢复：从库可以自动找到需要复制的位置
4. 支持多源复制：一个从库可以同时从多个主库复制数据

Q9：GTID的组成是什么？

答：GTID = source_id:transaction_id

• source_id：主库的server_uuid，唯一标识一个MySQL实例
• transaction_id：该主库上执行的事务序号，从1开始递增

三、主从延迟问题与解决方案

Q10：什么是主从延迟？如何衡量主从延迟？

答：主从延迟是指主库执行事务的时间与从库执行完该事务的时间差。

常用衡量方式：

• Seconds_Behind_Master：show slave status输出的估算值
• pt-heartbeat：Percona Toolkit提供的工具，通过定期写入时间戳来精确计算延迟
• 自定义时间戳表：在主库定期写入时间戳，从库读取计算差值

Q11：Seconds_Behind_Master指标有什么局限性？

答：

• 它是一个估算值，不是精确值
• 当主库没有写入时，该值会保持不变，无法反映真实延迟
• 大事务执行时，该值会突然增大，然后突然减小
• 网络中断时，该值不会立即更新

Q12：主从延迟产生的根本原因有哪些？最主要的原因是什么？

答：

1. 主库端原因：写入压力过大、硬件性能不足、大事务执行、binlog刷盘策略过于严格
2. 网络传输原因：网络延迟高、带宽不足
3. 从库端原因（最主要原因）：
   • MySQL 5.6之前SQL线程是单线程，无法并行执行relay log事件
   • 从库硬件性能差
   • 从库同时承担大量读请求
   • 大事务重放

Q13：MySQL并行复制有哪几种实现方式？各自的原理是什么？

答：

1. MySQL 5.6：基于库的并行复制
   • 原理：不同数据库的事务可以并行执行
   • 缺点：并行度低，只有一个库时无法并行
2. MySQL 5.7：基于组提交的并行复制
   • 原理：主库上同一组提交的事务，在从库上可以并行执行
   • 配置：slave_parallel_type=LOGICAL_CLOCK
3. MySQL 8.0：基于writeset的并行复制
   • 原理：不冲突的事务（修改不同行）可以并行执行
   • 并行度更高，性能更好

Q14：如何从业务层面解决主从延迟问题？

答：

1. 避免大事务：将大事务拆分为多个小事务（如批量删除每次删1000行）
2. 避免业务高峰期执行DDL：使用Online DDL工具（pt-online-schema-change、gh-ost）
3. 控制从库读压力：
   • 对延迟敏感的读请求走主库
   • 对延迟不敏感的读请求走从库
   • 使用Redis等缓存减轻数据库读压力
4. 避免在从库执行复杂查询：将复杂查询迁移到专门的分析库

四、半同步复制

Q15：异步复制存在什么问题？

答：

• 数据丢失风险：主库宕机时，部分binlog可能还没有发送到从库
• 数据不一致：主库宕机后提升从库为主库，会丢失未复制的数据
• 无法保证数据持久性：客户端收到事务提交成功的响应，但数据可能只存在于主库

Q16：半同步复制的原理是什么？与异步复制的关键区别是什么？

答：半同步复制的核心思想是：主库提交事务时，必须等待至少一个从库收到并写入relay log后，才向客户端返回提交成功。

关键区别：

• 异步复制：主库写入binlog → 立即返回客户端成功
• 半同步复制：主库写入binlog → 等待至少一个从库ACK → 返回客户端成功

Q17：半同步复制有哪两种模式？各自存在什么问题？

答：

1. AFTER_COMMIT模式（MySQL 5.5-5.6默认）
   • 流程：主库写入binlog → 提交到存储引擎 → 等待从库ACK → 返回成功
   • 问题：幻读问题。主库已经提交事务到存储引擎，其他客户端可以读取到该事务；如果此时主库宕机，从库没有收到该事务，提升从库为主库后，数据会"消失"
2. AFTER_SYNC模式（MySQL 5.7默认，增强半同步）
   • 流程：主库写入binlog → 等待从库ACK → 提交到存储引擎 → 返回成功
   • 解决了幻读问题，数据一致性更高

Q18：半同步复制有哪些局限性？

答：

1. 性能损耗：相比异步复制，性能下降约5%-20%
2. 超时降级：如果从库响应超时（默认10秒），会自动降级为异步复制，失去数据一致性保证
3. 无法解决主从延迟：只保证binlog发送到从库，不保证从库已经执行完成
4. 单点故障：仍然是一主多从架构，主库故障需要第三方工具切换
5. 脑裂问题：网络分区时可能出现双主，导致数据不一致

五、MySQL Group Replication (MGR)

Q19：什么是MGR？它的核心特性是什么？

答：MGR是MySQL官方推出的基于Paxos一致性协议的分布式高可用解决方案。

核心特性：

• 强一致性：基于Paxos协议，保证数据在多数节点上持久化
• 自动故障检测：自动检测节点故障
• 自动故障切换：主库故障时自动选举新主库
• 自动成员管理：节点加入或离开集群自动处理
• 支持单主和多主模式

Q20：MGR集群为什么需要奇数个节点？最少需要几个节点？

答：MGR基于多数派机制实现一致性和脑裂防护。

• 奇数个节点可以避免出现平票情况，确保能够选出多数派
• 最少需要3个节点组成集群（2个节点无法形成多数派，任何一个节点故障都会导致集群不可用）
• 最多支持9个节点

Q21：MGR的两种模式是什么？各自的适用场景是什么？

答：

1. 单主模式（推荐）
   • 特点：只有一个主节点处理所有写请求，其他节点只能处理读请求
   • 优势：没有写冲突问题，性能更好，与传统主从复制兼容
   • 适用场景：绝大多数业务场景
2. 多主模式
   • 特点：所有节点都可以处理写请求
   • 优势：写能力可以扩展到多个节点
   • 劣势：存在写冲突问题，性能不如单主模式
   • 适用场景：有特殊写扩展需求，且能避免同时修改同一行的场景

Q22：MGR是如何解决脑裂问题的？

答：MGR基于多数派机制解决脑裂问题：

• 只有获得多数节点（> N/2）支持的分区才能继续提供服务
• 少数派分区会自动变为只读状态，无法处理写请求
• 这样就避免了网络分区时出现两个都能处理写请求的主节点

Q23：MGR相比传统主从复制有哪些优势？

答：

1. 强一致性：保证数据在多数节点上持久化，不会丢失数据
2. 自动故障切换：主库故障时自动选举新主库，无需人工干预
3. 自动成员管理：节点加入或离开集群自动处理
4. 内置脑裂防护：基于多数派机制，从根本上避免脑裂问题
5. 官方支持：与MySQL无缝集成，持续更新维护

Q24：MGR有哪些局限性？

答：

1. 性能损耗：相比异步复制，性能下降约30%-50%
2. 网络要求高：节点之间需要低延迟、高带宽的网络
3. 集群规模限制：最多支持9个节点
4. 功能限制：
   • 不支持MyISAM存储引擎
   • 不支持外键级联操作
   • 不支持大事务（建议事务大小不超过1GB）
5. 运维复杂度高：相比传统主从复制，MGR的运维更复杂

六、高可用方案选型与对比

Q25：对比异步复制、半同步复制和MGR的核心差异。

答：

Q26：不同业务场景下应该如何选择MySQL高可用方案？

答：

1. 小型业务/测试环境：异步主从复制 + 手动切换
   • 优点：简单、性能好、运维成本低
2. 中型业务/核心业务：增强半同步复制 + MHA/Orchestrator
   • 优点：数据一致性较高、自动故障切换、性能较好
3. 大型业务/金融级业务：MySQL MGR + ProxySQL
   • 优点：强一致性、自动故障切换、无数据丢失、内置脑裂防护
4. 跨地域高可用：主从复制 + 跨地域灾备（MGR跨地域对网络延迟要求极高）

Q27：MHA和Orchestrator是什么？它们在高可用架构中扮演什么角色？

答：MHA（Master High Availability）和Orchestrator都是MySQL主从复制的自动故障切换工具。

它们的作用：

• 自动检测主库故障
• 自动选择最适合的从库提升为主库
• 自动调整其他从库的复制关系，指向新的主库
• 弥补了传统主从复制和半同步复制没有自动故障切换的缺陷

Q28：ProxySQL在MySQL高可用架构中起到什么作用？

答：ProxySQL是一个高性能的MySQL中间件，在高可用架构中起到以下作用：

1. 读写分离：自动将写请求转发到主库，读请求转发到从库
2. 负载均衡：将读请求均匀分发到多个从库
3. 故障自动切换：主库故障时，自动将写请求转发到新的主库
4. 连接池：管理数据库连接，减少数据库的连接压力
5. SQL过滤和路由：可以根据SQL语句进行过滤和路由

《MySQL高可用面试常见陷阱题与易错点总结》

一、基础概念与高可用概述

陷阱1：高可用计算的时间单位陷阱

问题："四个九"的可用性意味着每月最多允许多少分钟的停机时间？
易错点：直接用年停机时间除以12，得到约4.38分钟，但这是错误的。
正确解答：

• 年停机时间：365×24×60×(1-0.9999)=52.56分钟
• 月平均停机时间：52.56÷12=4.38分钟
• 但实际中不能这样简单计算，因为故障通常是集中发生的，而不是均匀分布的
• 面试官真正想考察的是你对高可用的理解，而不是简单的数学计算

陷阱2：高可用≠数据不丢失

问题：高可用系统是否一定不会丢失数据？
易错点：认为高可用就是数据不丢失。
正确解答：

• 高可用和数据一致性是两个不同的概念
• 高可用关注的是服务不中断，而数据一致性关注的是数据不丢失
• 例如：异步主从复制可以实现99.99%的可用性，但存在数据丢失的风险
• 只有同时满足高可用和强一致性的系统，才能保证服务不中断且数据不丢失

陷阱3："五个九"是否适合所有业务？

问题：我们的业务需要达到"五个九"的可用性，你觉得应该怎么做？
易错点：直接开始设计"五个九"的架构，而不考虑业务实际需求。
正确解答：

• 首先要明确："五个九"的可用性成本非常高，不是所有业务都需要
• "五个九"意味着年停机时间不超过5.26分钟，这需要极其复杂的架构和运维体系
• 应该先评估业务的实际需求：
  • 如果业务中断1小时损失100万，那么"四个九"就足够了
  • 如果业务中断1分钟损失100万，才需要考虑"五个九"
• 大多数互联网业务达到"四个九"就已经非常优秀了

二、主从复制原理

陷阱4：主库有几个Binlog Dump线程？

问题：主库上有几个Binlog Dump线程？
易错点：回答"1个"。
正确解答：

• 每个从库对应一个Binlog Dump线程
• 如果主库有N个从库，那么主库上就有N个Binlog Dump线程
• 这就是为什么从库数量过多会影响主库性能的原因之一

陷阱5：GTID复制是否完全不需要指定binlog位置？

问题：使用GTID复制后，是否永远不需要手动指定binlog文件名和位置了？
易错点：回答"是"。
正确解答：

• 大多数情况下，GTID复制不需要手动指定binlog位置
• 但在以下特殊情况下，仍然需要：
  • 从一个非GTID的主库迁移到GTID的主库
  • 恢复一个没有GTID信息的备份
  • 修复GTID复制的异常情况
• 例如：CHANGE MASTER TO MASTER_AUTO_POSITION=0, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

陷阱6：gtid_executed和gtid_purged的区别

问题：gtid_executed和gtid_purged有什么区别？
易错点：混淆这两个变量的含义。
正确解答：

• gtid_executed：表示已经在该实例上执行过的所有事务的GTID集合
• gtid_purged：表示已经被purge掉的binlog中包含的事务的GTID集合
• 关系：gtid_purged是gtid_executed的子集
• 重要性：当一个新的从库加入集群时，它只能复制gtid_executed - gtid_purged范围内的事务
• 如果从库需要的GTID已经被purge掉了，那么它无法通过主从复制来同步数据，必须使用备份恢复

陷阱7：binlog和relay log的区别

问题：binlog和relay log有什么区别？
易错点：认为它们是同一种东西。
正确解答：

陷阱8：多源复制和级联复制的区别

问题：多源复制和级联复制有什么区别？
易错点：混淆这两种复制架构。
正确解答：

• 多源复制：一个从库同时从多个主库复制数据
  • 用途：数据合并、多机房数据同步
  • 要求：MySQL 5.7及以上版本，必须使用GTID复制
• 级联复制：A→B→C，B既是A的从库，又是C的主库
  • 用途：减轻主库的压力，特别是当从库数量很多时
  • 要求：B必须开启binlog（log_slave_updates=1）

三、主从延迟问题与解决方案

陷阱9：Seconds_Behind_Master=0就意味着没有延迟吗？

问题：show slave status显示Seconds_Behind_Master=0，是否说明主从完全一致？
易错点：回答"是"。
正确解答：

• 不一定，Seconds_Behind_Master=0可能存在以下情况：
  1. 主库确实没有写入，从库完全同步
  2. 主库有写入，但从库IO线程已经接收完所有binlog，SQL线程正在执行，但Seconds_Behind_Master还没有更新
  3. 网络中断，从库IO线程已经停止，但Seconds_Behind_Master仍然显示0
• 这就是为什么不能只依赖Seconds_Behind_Master来监控主从延迟的原因

陷阱10：并行复制可以完全解决主从延迟吗？

问题：开启并行复制后，主从延迟问题就解决了吗？
易错点：回答"是"。
正确解答：

• 并行复制可以大大减轻主从延迟，但不能完全解决主从延迟
• 并行复制的并行度是有限的：
  • MySQL 5.6：只能基于库并行
  • MySQL 5.7：只能基于组提交并行
  • MySQL 8.0：基于writeset并行，但仍然只能并行执行不冲突的事务
• 以下情况仍然会导致主从延迟：
  • 大事务执行
  • 主库写入压力超过从库的并行重放能力
  • 从库硬件性能不足
  • 网络延迟过高

陷阱11：为什么大事务会导致主从延迟？

问题：为什么一个更新100万行的大事务会导致主从延迟激增？
易错点：只回答"因为数据量大"。
正确解答：

• 大事务导致主从延迟的原因有多个：
  1. 主库生成binlog时间长：大事务会生成大量的binlog，写入binlog需要时间
  2. 网络传输时间长：大量的binlog需要通过网络传输到从库
  3. 从库重放时间长：即使开启了并行复制，同一个事务内的操作也只能串行执行
  4. 阻塞其他事务：在MySQL 5.7之前，大事务会阻塞组提交，影响其他事务的并行重放
• 这就是为什么我们强烈建议将大事务拆分为多个小事务的原因

陷阱12：从库配置比主库好就不会有延迟吗？

问题：如果从库的硬件配置比主库好，是否就不会有主从延迟？
易错点：回答"是"。
正确解答：

• 不一定，即使从库配置比主库好，仍然可能出现主从延迟
• 原因：
  1. SQL线程单线程瓶颈：MySQL 5.6之前SQL线程是单线程，无论从库CPU有多好，都只能串行执行
  2. 并行复制的限制：即使开启了并行复制，并行度也是有限的
  3. 从库读压力：如果从库同时承担大量的读请求，会占用大量的CPU和IO资源
  4. 主库写入压力：如果主库写入压力非常大，binlog生成速度超过从库的重放能力

四、半同步复制

陷阱13：半同步复制可以保证数据不丢失吗？

问题：使用半同步复制后，是否一定不会丢失数据？
易错点：回答"是"。
正确解答：

• 不一定，半同步复制仍然存在数据丢失的风险：
  1. 超时降级风险：如果从库响应超时（默认10秒），半同步复制会自动降级为异步复制，此时就存在数据丢失的风险
  2. AFTER_COMMIT模式的幻读问题：在MySQL 5.5-5.6的默认模式下，主库已经提交事务到存储引擎，其他客户端可以读取到该事务，如果此时主库宕机，从库没有收到该事务，数据就会丢失
  3. 所有从库都宕机：如果主库提交事务后，所有从库都宕机，那么数据就只存在于主库，如果主库也宕机，数据就会丢失
• 只有当使用AFTER_SYNC模式，并且至少有一个从库正常运行时，半同步复制才能保证数据不丢失

陷阱14：半同步复制可以解决主从延迟吗？

问题：半同步复制可以解决主从延迟问题吗？
易错点：回答"是"。
正确解答：

• 不能，半同步复制和主从延迟是两个不同的概念
• 半同步复制只保证binlog已经发送到从库并写入relay log，但不保证从库已经执行完这些binlog
• 从库执行relay log的过程仍然是异步的，所以半同步复制无法解决主从延迟问题
• 实际上，半同步复制会稍微增加主从延迟，因为主库需要等待从库的ACK

陷阱15：rpl_semi_sync_master_wait_for_slave_count设置得越大越好吗？

问题：将rpl_semi_sync_master_wait_for_slave_count设置为更大的值，是否可以提高数据安全性？
易错点：回答"是"。
正确解答：

• 理论上，设置更大的值可以提高数据安全性，因为需要更多的从库确认收到binlog
• 但实际上，这个值设置得越大，性能损耗就越大，可用性就越低
• 例如：如果设置为2，那么当有2个从库宕机时，主库就无法提交任何事务
• 推荐设置：1，这是性能和安全性的最佳平衡点
• 如果需要更高的数据安全性，可以考虑使用MGR

五、MySQL Group Replication (MGR)

陷阱16：MGR是同步复制吗？

问题：MGR是同步复制吗？
易错点：回答"是"。
正确解答：

• 不是，MGR是半同步复制的一种，或者说是最终一致性复制
• MGR的事务执行流程：
  1. 主库生成writeset并广播到所有节点
  2. 多数节点确认收到writeset
  3. 主库提交事务并返回客户端成功
  4. 从库异步重放事务
• 所以，当客户端收到事务提交成功的响应时，从库可能还没有执行完该事务，仍然存在主从延迟
• MGR保证的是数据最终一致性，而不是实时一致性

陷阱17：MGR完全解决了脑裂问题吗？

问题：MGR是否完全解决了脑裂问题？
易错点：回答"是"。
正确解答：

• MGR从机制上避免了脑裂问题，但在某些极端情况下仍然可能出现脑裂
• MGR的脑裂防护机制：
  • 只有获得多数节点（> N/2）支持的分区才能继续提供服务
  • 少数派分区会自动变为只读状态
• 极端情况：
  • 当集群出现多个分区，每个分区都有多数节点时，就会出现脑裂
  • 这种情况只有在集群节点数≥5时才可能发生（例如：5个节点分成2个分区，3个和2个，不会脑裂；但如果分成3个分区，2个、2个、1个，也不会脑裂）
  • 实际上，只要正确部署MGR集群（奇数个节点，网络可靠），脑裂问题几乎不会发生

陷阱18：MGR的单主模式和传统主从复制有什么区别？

问题：MGR的单主模式和传统的主从复制有什么区别？
易错点：认为它们是一样的。
正确解答：

陷阱19：MGR最多支持多少个节点？为什么？

问题：MGR最多支持多少个节点？为什么有这个限制？
易错点：不知道具体数字，或者不知道原因。
正确解答：

• MGR最多支持9个节点
• 原因：
  1. Paxos协议的性能限制：节点数越多，达成共识的时间就越长，性能就越低
  2. 网络带宽限制：每个节点都需要和其他所有节点通信，节点数越多，网络开销就越大
  3. 故障检测的准确性：节点数越多，误判故障的概率就越高
• 推荐集群规模：3-5个节点，这是性能和可用性的最佳平衡点

陷阱20：MGR不支持哪些功能？

问题：MGR有哪些功能限制？
易错点：只知道不支持MyISAM。
正确解答：
MGR有以下重要的功能限制：

1. 不支持MyISAM存储引擎：所有表必须使用InnoDB存储引擎
2. 不支持外键级联操作：ON DELETE CASCADE和ON UPDATE CASCADE可能导致冲突检测失败
3. 不支持大事务：建议事务大小不超过1GB，否则可能导致集群不可用
4. 不支持SERIALIZABLE隔离级别
5. 不支持临时表：MySQL 8.0.13及以上版本支持
6. 不支持复制过滤：replicate_do_db、replicate_ignore_db等参数不支持

六、高可用方案选型与实践

陷阱21：MGR是万能的吗？

问题：既然MGR这么好，为什么不是所有公司都使用MGR？
易错点：认为MGR适合所有场景。
正确解答：

• MGR虽然有很多优点，但并不是万能的，它也有自己的局限性：
  1. 性能损耗大：相比异步复制，性能下降约30%-50%
  2. 网络要求高：节点之间需要低延迟、高带宽的网络，不适合跨地域部署
  3. 运维复杂度高：相比传统主从复制，MGR的运维更复杂，需要更高的技术水平
  4. 功能限制多：如不支持外键级联、大事务等
• 所以，MGR更适合金融、电信等对数据一致性要求极高的业务，而对于大多数互联网业务来说，增强半同步复制+MHA/Orchestrator已经足够了

陷阱22：MHA和Orchestrator应该选择哪个？

问题：MHA和Orchestrator都是MySQL自动故障切换工具，应该选择哪个？
易错点：不知道它们的区别。
正确解答：

• 推荐选择Orchestrator，因为它有更好的架构、更活跃的社区和更友好的可视化界面
• MHA虽然经典，但作者已经停止维护，未来可能会被淘汰

陷阱23：跨地域高可用应该如何设计？

问题：如何设计跨地域的MySQL高可用架构？
易错点：直接部署跨地域的MGR集群。
正确解答：

• 跨地域高可用的最大挑战是网络延迟高
• 不建议部署跨地域的MGR集群，因为MGR对网络延迟非常敏感，会导致性能急剧下降
• 推荐的跨地域高可用架构：
  1. 主从复制+跨地域灾备：
     • 主集群部署在主地域
     • 从集群部署在灾备地域
     • 使用异步或半同步复制
     • 主地域故障时，手动或自动切换到灾备地域
  2. 两地三中心架构：
     • 主中心和同城备中心部署MGR集群
     • 异地灾备中心部署从库
     • 同城故障时自动切换，异地故障时手动切换

陷阱24：如何处理主从复制的异常中断？

问题：如果主从复制中断了，应该如何处理？
易错点：直接跳过错误。
正确解答：

• 主从复制中断的处理步骤：
  1. 查看错误信息：执行show slave status\G，查看Last_IO_Error和Last_SQL_Error
  2. 分析错误原因：
     • IO线程错误：通常是网络问题、主库宕机、权限问题
     • SQL线程错误：通常是数据不一致、主键冲突、DDL执行失败
  3. 根据错误原因处理：
     • 网络问题：修复网络，重新连接主库
     • 数据不一致：如果是小问题，可以手动修复；如果是大问题，需要重新搭建从库
  4. 谨慎跳过错误：只有在确认跳过错误不会导致数据不一致的情况下，才可以使用SET GLOBAL sql_slave_skip_counter=N（传统复制）或SET GTID_NEXT='xxx:N'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';（GTID复制）

七、终极面试陷阱：场景题

陷阱25：主库宕机了，你会怎么做？

问题：如果生产环境的主库突然宕机了，你会怎么做？
易错点：直接回答"切换到从库"。
正确解答：

• 这是一个非常经典的场景题，面试官想考察的是你的应急处理能力和思维的全面性
• 正确的处理流程：
  1. 确认故障：首先确认主库确实宕机了，而不是网络问题或监控误报
  2. 评估影响：评估故障对业务的影响，通知相关人员
  3. 选择切换方案：
     • 如果有自动故障切换工具（如MHA、Orchestrator、MGR），等待自动切换
     • 如果没有自动故障切换工具，手动切换到从库
  4. 手动切换步骤：
     • 选择数据最完整的从库（show slave status查看Relay_Master_Log_File和Exec_Master_Log_Pos）
     • 在该从库上执行STOP SLAVE; RESET MASTER;
     • 在其他从库上执行CHANGE MASTER TO MASTER_HOST='新主库IP'
     • 通知应用切换到新主库
  5. 恢复原主库：原主库恢复后，将其作为从库加入集群
  6. 事后分析：分析主库宕机的原因，采取措施避免再次发生