MySQL 数据库双机热备怎么做？

MySQL 是全球部署量最大的开源关系型数据库之一。在企业的生产环境中，MySQL 常作为交易系统、内容管理系统和 Web 应用的后端数据库，其可用性直接影响核心业务的正常运行。

MySQL 的双机热备可以借助数据库自身的复制机制实现，也可以通过操作系统层面的高可用软件实现。两种路径在适用条件、故障切换方式和保护范围上存在差异。本文分别阐述。

一、基于 MySQL 原生复制的主备方案

工作原理

MySQL 自 3.23 版本起提供了主从复制（Replication）机制。主库（Master）将数据变更记录为二进制日志（Binary Log），从库（Slave）通过 I/O 线程从主库拉取日志并写入中继日志（Relay Log），再由 SQL 线程在中继日志上重放 SQL 操作，最终实现数据同步。

在主从复制架构中，业务写操作全部指向主库，从库提供只读查询服务以实现读写分离。当主库发生故障时，需要人工或脚本将应用连接切换至从库，并将从库提升为新主库。

原生主从复制的局限在于：切换过程需要人工介入（或依赖外部切换脚本），不具备自动故障检测和资源切换能力；主从之间存在复制延迟，在异步复制模式下延迟可能在秒级至分钟级，切换时存在数据丢失风险；应用层需要感知主从角色变化并修改数据库连接地址。

半同步复制

MySQL 5.5 引入的半同步复制（Semi-Synchronous Replication）在一定程度上弥补了异步复制的数据丢失问题。半同步模式下，主库提交事务后至少等待一个从库确认已接收并写入中继日志，才向客户端返回提交成功。此机制将切换时的数据丢失窗口从"主库故障前的未同步窗口"压缩为"已接收但未执行的最后一个事务"。

半同步复制的代价是主库写入性能受从库网络延迟影响。在同机房或同城低延迟网络环境下，性能影响可控；跨地域高延迟环境下影响显著。

适用评价

MySQL 原生主从复制适合以下场景：对故障切换自动化要求不高，可接受人工切换；从库承担读负载，读写分离是架构中的主要诉求；团队对 MySQL 运维经验丰富，能够管理复制链路的状态监控和故障恢复。

该方案的局限在于：不具备自动故障检测和切换能力，需要外部组件补足；应用层需配合连接切换机制；切换过程中存在数据丢失风险（异步模式下）。

二、基于高可用软件的双机热备方案

对于需要自动故障检测、自动切换和零数据丢失（共享存储模式下）的场景，采用操作系统层面的高可用软件管理 MySQL 是更稳健的方案。

2.1 共享存储方案

两台服务器通过 FC、SAS 或 iSCSI 链路连接至同一磁盘阵列。MySQL 的数据文件、日志文件和配置文件全部存储在阵列的共享逻辑卷上。同一时刻只有活动节点挂载该逻辑卷并启动 MySQL 服务，备用节点的 MySQL 处于停止状态。

高可用软件（如 RoseHA）负责以下工作：通过心跳链路监控两台服务器的运行状态和 MySQL 进程状态；检测到活动节点故障后，自动将共享逻辑卷和虚拟 IP 转移至备用节点；在备用节点上按预设顺序启动 MySQL 服务；切换完成后对外提供数据库服务。

共享存储方案的核心优势在于数据只有一份，不存在主备数据不一致的问题，切换后数据零丢失。在性能层面，MySQL 直接读写阵列上的数据文件，不存在复制延迟对写入性能的影响。

部署要点：两台服务器的 MySQL 配置文件（my.cnf）必须完全一致，包括数据目录路径、日志文件路径和内存参数；阵列上的逻辑卷应使用支持并发挂载控制的文件系统或卷管理器，防止脑裂时两端同时写入；心跳链路应配置至少两条独立路径，其中建议包含一条网线直连。

2.2 纯软件镜像方案

在没有共享存储的环境中，可以采用纯软件镜像方案。两台服务器各自使用本地磁盘，高可用软件（如 RoseMirrorHA）通过过滤驱动捕获 MySQL 数据目录下所有文件的实时变更，将变更字节以镜像方式同步至备用节点。

活动节点上的 MySQL 正常读写本地数据文件，镜像驱动在文件系统层或卷层捕获写入操作，将变化数据实时传输至备用节点的对应路径。备用节点上的 MySQL 服务处于停止状态，但数据文件与活动节点保持实时同步。

故障切换时，备用节点确认数据副本完整性后，挂载数据目录、启动 MySQL 服务并接管虚拟 IP。镜像方案的 RPO 取决于镜像模式。同步镜像模式下，活动节点每次写入需等待备用节点确认，RPO 为零；异步镜像模式下，RPO 在毫秒至秒级。对于 MySQL 这类对写入延迟较敏感的 OLTP 数据库，同步镜像需要评估网络延迟对事务提交时间的影响。

部署要点：镜像范围应精确限定为 MySQL 数据目录，排除临时文件和操作系统无关目录，避免无效复制浪费带宽；备用节点的硬件配置（CPU、内存、磁盘 I/O 性能）应与活动节点相当，以确保接管后的数据库性能不出现显著下降；MySQL 的 InnoDB 缓冲池预热策略应在切换脚本中予以考虑——接管后使用备份或预热脚本加载热数据至缓冲池，避免刚接管时的查询性能骤降。

三、两种方案对比

四、MySQL 双机热备的关键注意事项

崩溃恢复后的数据一致性。 MySQL 使用 InnoDB 存储引擎时，实例崩溃恢复依赖重做日志（Redo Log）。在共享存储方案中，故障节点的 MySQL 实例崩溃后，备用节点启动 MySQL 时会自动执行 InnoDB 崩溃恢复流程，利用重做日志将数据恢复至一致状态。这一过程耗时取决于重做日志的大小和检查点间隔，通常在数秒至数十秒，应纳入 RTO 的规划设计。

连接切换。 MySQL 客户端在连接中断后不会自动重连。应用层应配置连接池的重连机制，或在数据库连接 URL 中指定自动重连参数。同时，DNS 或虚拟 IP 切换的生效速度决定了客户端从感知故障到完成重连的总耗时。

避免脑裂场景下的数据损坏。 在共享存储方案中，高可用软件必须配置仲裁机制，绝对杜绝两个节点同时挂载数据卷并启动 MySQL 的情况。InnoDB 在双写场景下会导致不可恢复的数据损坏。

五、总结

MySQL 双机热备的路径选择取决于三个关键因素：是否需要自动故障切换（决定是否引入高可用软件），机房是否具备共享存储条件（决定存储模式），以及对 RPO 的要求（决定同步还是异步复制）。

对于生产级的 MySQL 双机热备部署，高可用软件 + 共享存储或镜像的方案在自动化和可靠性上显著优于纯原生复制方案。如果机房具备共享存储基础设施，共享存储方案以零 RPO 和最短 RTO 为最优选择；如果不具备共享存储条件，镜像方案是等效的替代路径。