面试题：MySQL IP 接管技术中的数据一致性保障

Question

在 MySQL 的 IP 接管场景中，当主库发生故障，从库接管虚拟 IP 成为新的主库后，如何确保数据的一致性？请详细说明可能遇到的数据不一致情况（如网络分区导致的双活等），以及针对这些情况你所知道的解决方案和实现原理。

Answer 1

可能遇到的数据不一致情况

1. 网络分区导致双活：在网络分区期间，主从库之间的网络连接中断，原主库和新接管的从库（新主库）可能会各自独立接受写入操作，导致数据冲突和不一致。例如，原主库上更新了一条记录，新主库在不知情的情况下也对同一条记录进行了不同的更新。
2. 复制延迟问题：在主库故障前，从库可能存在复制延迟，即从库尚未完全同步主库的所有数据。当从库接管成为新主库后，可能会丢失主库故障前的部分最新数据。

解决方案及实现原理

1. 基于 GTID（全局事务标识符）的复制
   • 原理：GTID 是 MySQL 5.6 引入的特性，每个事务在主库上执行时都会被分配一个唯一的 GTID。从库通过记录和跟踪 GTID 来确保准确复制主库的事务。当主库发生故障，从库接管成为新主库后，新主库可以通过 GTID 来识别并应用尚未同步的事务，从而保证数据一致性。例如，原主库执行事务 T1，其 GTID 为 gtid1，从库在同步时会记录 gtid1，如果在故障前从库未同步完 T1，成为新主库后，可依据 GTID 继续应用 T1。
   • 优点：简单高效，能够快速恢复数据一致性，减少手动干预。
2. 半同步复制（Semi - synchronous Replication）
   • 原理：在半同步复制模式下，主库在提交事务前，需要等待至少一个从库确认接收到该事务的二进制日志。这确保了在主库故障时，至少有一个从库保存了最新的事务数据。当从库接管成为新主库后，由于已经接收了主库故障前的最新事务日志，能有效避免数据丢失。例如，主库执行事务 T2，在提交前等待从库 A 确认接收日志，从库 A 确认后，主库提交 T2，此时即使主库故障，从库 A 成为新主库也不会丢失 T2。
   • 优点：提高数据安全性，降低数据丢失风险，但可能会略微增加主库的事务提交延迟。
3. 设置合适的复制过滤和同步策略
   • 原理：通过合理配置复制过滤规则，可以确保在主从切换过程中，新主库不会重复应用已经同步过的事务，也不会遗漏重要事务。例如，可以基于数据库名、表名等进行过滤，只让相关的事务在新主库上正确应用。同时，采用合适的同步策略，如在切换前等待从库完全同步主库数据（通过监控复制状态变量 Seconds_Behind_Master 为 0），确保从库数据完整。
   • 优点：可根据实际业务场景灵活调整，减少不必要的复制操作，但需要对业务有深入了解，配置过程相对复杂。
4. 使用分布式一致性协议（如 Paxos、Raft 等）
   • 原理：以 Raft 为例，MySQL 集群中的节点通过 Raft 协议选举出领导者（主库），在数据写入时，领导者将数据同步给其他节点（从库）。当主库故障时，Raft 协议会重新选举新的领导者（从库接管成为新主库），并且新领导者能够确保数据的一致性，因为只有成功同步到多数节点的数据才能被提交。例如，一个包含 5 个节点的集群，写入事务 T3 时，领导者将 T3 同步给至少 3 个节点（包括自身）后才提交 T3，若领导者故障，新选举出的领导者必然包含 T3，保证数据一致性。
   • 优点：具有较高的容错性和数据一致性保障，但引入了额外的复杂度，需要对分布式系统有深入理解和一定的开发成本。