如何为 MySQL 主从架构配置自动故障切换

你可以借助 Keepalived、MySQL Utilities 或 MySQL InnoDB Cluster 等工具，为 MySQL 主从架构配置自动故障切换。本文将带你依次完成前置条件准备、复制配置、故障切换工具部署、测试以及最佳实践。Keepalived 通过管理虚拟 IP 实现高可用，而 MySQL Utilities 和 InnoDB Cluster 则可以在主库故障时提升新的主库。本文默认你已经掌握基本的 MySQL 命令，并且至少准备好了两台服务器。你将学会如何在主库宕机时保护数据一致性，并尽可能维持业务可用性。按照本文步骤操作，你可以建立一套值得信赖的故障切换方案。

MySQL 复制的前置条件

服务器与网络要求

在构建任何故障切换方案之前，你至少需要两台服务器。其中一台作为主库，负责处理所有写入流量；另一台作为从库，接收主库的全部变更副本。为每台主机分配静态 IP 地址、可解析的主机名，以及稳定可靠的网络连接。连接中断是触发故障切换最常见的原因之一，因此网络本身就是架构设计的一部分，而不是事后补救项。

故障切换通常会因三类问题被触发：节点之间的网络中断、主库所在机器宕机，或者 MySQL 服务本身被关闭。对故障切换工具来说，这三种情况表现并不相同，因此你必须为每种情况设计清晰的应对策略。你也可以采用主主架构，即每个主库各自复制到自己的从库。这种设计增加了数据冗余，但你的故障切换方案仍然必须在每个主库各自拥有从库的前提下，准确提升正确的节点。务必充分测试这种拓扑，因为一旦提升错误节点，就会破坏整个架构的一致性。

MySQL 安装与版本兼容性

在所有节点上安装相同版本的 MySQL。版本不一致可能会在一些细节上破坏 MySQL 复制，尤其是在二进制日志格式在不同版本之间发生变化时更是如此。在开始配置之前，先检查每台主机上的版本，并优先升级不一致的服务器。在 Ubuntu 或 Debian 上，主配置文件位于 /etc/mysql/mysql.conf.d/mysqld.cnf，稍后你需要在主库上修改它。

在调整复制设置之前，先规划好监控方案。你需要一种方法来快速检测主库是否失效，也需要一种方法来确认副本是否健康且已经追平。提前确定由哪种工具负责监控集群、检查频率是多少，以及故障时通知谁。这里的规划越扎实，真实故障发生时就越不容易出意外。服务器准备完毕且版本一致后，就可以进入复制配置阶段。

配置 MySQL 主从复制

设置主库服务器

先从你选定为主库的那台机器开始。在 Ubuntu 或 Debian 上，打开 /etc/mysql/mysql.conf.d/mysqld.cnf，设置唯一的服务器 ID，启用二进制日志，并指定日志文件名称。这些设置可以让主库记录每一次变更，并将其提供给各个副本。

[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_do_db = appdb

保存文件后重启服务。接着，创建一个专用于 MySQL 复制的账户，并授予它 REPLICATION SLAVE 权限。短暂锁表后，读取当前的二进制日志位置，并记录日志文件名和偏移量。这个位置就是每个从库开始复制数据的起点。

配置从库并启动复制

切换到从库主机，编辑它自己的配置文件。为其分配不同的服务器 ID，然后重启服务。接着使用你刚才记录的日志文件和位置，通过 CHANGE MASTER TO 语句将从库指向主库。

CHANGE MASTER TO
  MASTER_HOST='192.0.2.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='secret',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;
START SLAVE;

执行 SHOW SLAVE STATUS，并确认 Slave_IO_Running 和 Slave_SQL_Running 都显示为 Yes。若你需要配置一个主库同时复制到多个从库，Oracle Utilities 可以自动化这一步。通过在主库写入一条记录、再到从库读取该记录，测试 MySQL 复制是否正常。随后在两端执行校验和比对，以验证数据一致性，确保复制链路真正可靠。到这一步，一个健康的从库就已经能够镜像主库，并准备好接入故障切换工具。

为 MySQL 配置自动故障切换

现在，你已经让 MySQL 复制正常工作。下一步就是加入一个可以在主库故障时自动接管的机制。生产环境中主要有两种思路：Keepalived 负责在主机之间漂移虚拟 IP；MySQL Utilities 和 InnoDB Cluster 则直接将从库提升为主库。你也可以组合使用这些工具，以获得更高的数据冗余和可靠性。

使用 Keepalived 和虚拟 IP

Keepalived 运行在两台服务器上，并通过 VRRP 共享一个浮动 IP 地址。正常情况下，这个虚拟 IP 由主库持有；一旦主库发生故障，Keepalived 就会将该 IP 漂移到从库。应用程序始终连接同一个地址，因此几乎感知不到切换过程。这种设计在尽量少改动应用架构的前提下，实现了高可用。

Keepalived 的配置文件位于 /etc/keepalived/keepalived.conf。在主库上，你需要定义一个健康检查脚本以及一个 VRRP 实例。下面的示例展示了来自实际部署的语法结构。

将这份配置复制到从库，并把状态改成 BACKUP，同时将优先级降低为 101。然后在两台机器上重启 keepalived 服务。该服务每两秒检查一次 MySQL 状态。当主库宕机后，健康检查会失败，备库会在几秒内接管虚拟 IP。这样一来，你无需修改应用配置，也能获得故障切换能力。

使用 MySQL Utilities 或 InnoDB Cluster

MySQL Utilities 提供了两个处理主库故障切换的命令行工具。mysqlrpladmin 用于执行受控切换，而 mysqlfailover 则会持续监控主库，并在主库故障时自动触发故障切换。

你可以通过运行 mysqlfailover --master=root@utils1:3306 --discover-slaves-login=root --rediscover 进入监控模式。它会每隔几秒检查一次主库状态。一旦发现故障，它会识别最合适的从库进行提升。该工具还会在提升前尝试从其他从库补齐缺失事件。你也可以限制哪些从库有资格被提升，或者配置自定义的故障切换前后脚本。

MySQL InnoDB Cluster 则采用了另一种思路。它基于 Group Replication，而 Group Replication 提供的是同步复制。下表对比了 Group Replication 与传统异步主从复制之间的差异。

如果你需要强一致性，并且能够接受更高的写入延迟，那么请选择 Group Replication。如果你更重视较简单的部署方式和较低的运行开销，那么传统复制配合 Keepalived 或 MySQL Utilities 会更适合。无论选择哪种方案，都要彻底测试故障切换配置。模拟主库崩溃，并验证虚拟 IP 是否发生漂移、从库是否被正确提升。

测试故障切换与最佳实践

模拟主库故障

在真正发生故障之前，你必须证明你的配置确实可用。停止主库上的 MySQL 服务，并观察系统行为。Keepalived 会通过健康检查脚本检测到进程失效，并在几秒内将虚拟 IP 漂移到从库。你的应用程序无需人工干预，就能重新连接到新的地址。

最好在维护窗口期间执行这类演练。确认从库已经被提升为主库，并且能够正常接受写入。同时检查旧主库恢复后，是否能重新以副本身份加入集群。Keepalived 负责处理 IP 漂移，但你的提升脚本仍然需要在新主库上重置复制关系。故障切换完成后，还要验证复制健康监控工具是否显示状态正常。

避免脑裂与数据丢失

脑裂指的是两个节点都认为自己是主库，并同时接受写入，最终导致数据分叉。MySQL InnoDB Cluster 通过法定多数机制来防止这种情况。只有当大多数节点都确认后，写操作才会提交。这种基于 Paxos 的共识机制，正是它在网络分区场景下防止脑裂的核心原理。

偶数节点集群并不安全。若发生 50/50 分裂，任何一侧都无法获得多数，因此双方都会拒绝写入。这种做法牺牲了一部分可用性，但换来了数据一致性保护。

请遵循以下规则来保护你的数据：先确认主库确实已经失效，再执行故障切换；一次故障只切换一次，绝不要提升一个不一致的从库；所有写入都必须只发送到主库；故障切换完成后，及时更新应用配置，使其指向新的主库；并且一定要先在预发布或测试环境中验证配置。

自动故障切换建立在三个支柱之上：可用的复制链路、可靠的故障切换工具，以及反复的测试演练。应根据你的拓扑选择合适的工具。Keepalived 适合简单的虚拟 IP 故障切换，而 MySQL Utilities 或 InnoDB Cluster 更适合具备拓扑感知能力的主库提升场景。

接下来，你应该加入监控、定期安排故障切换演练，并在每次测试后复查 MySQL 日志。每一次演练都应先在测试环境完成，再推广到生产环境。这样的习惯能更好地保护数据，并维持高可用性。

常见问题

自动故障切换一般需要多长时间？

Keepalived 每两秒检查一次主库状态，一旦健康检查失败，就会漂移虚拟 IP，因此切换通常会在数秒内完成。MySQL Utilities 和 InnoDB Cluster 提升新主库的耗时也大致相似。实际所需时间仍取决于你的监控间隔和网络状况。

没有虚拟 IP 也能实现故障切换吗？

可以。MySQL Utilities 和 InnoDB Cluster 都可以直接提升副本，因此你的应用程序需要重新连接到新的主机。虚拟 IP 的优势在于保持访问地址不变，从而免去应用层重新配置。具体采用哪种方式，应根据你的应用能接受多大改动来决定。

故障切换后，旧主库会怎么样？

旧主库恢复后，会以副本身份重新加入。你的提升脚本会通过 CHANGE MASTER TO 将它重新指向新的主库。务必确认复制恢复正常，并确保在故障期间没有任何写入落到这个已被降级的节点上。

自动故障切换会导致写入丢失吗？

在异步复制架构中，确实有这种可能。如果主库在副本拉取到最新二进制日志事件之前崩溃，那么最近的一部分变更可能会丢失。InnoDB Cluster 通过同步的 Group Replication 和基于法定多数的提交机制避免了这个问题。而传统架构则需要接受一个小范围的数据丢失窗口。

要实现安全故障切换，至少需要多少个节点？

三个节点可以形成 2 的法定多数，并容忍 1 个节点故障。偶数节点集群并不安全，因为发生 50/50 分裂时，任何一侧都拿不到多数。对于简单的虚拟 IP 故障切换，Keepalived 双机方案已经可行；但对于依赖法定多数机制的方案，则需要使用奇数节点。