mysql半一致性_MySQL半同步复制的数据一致性探讨

在线QQ客服：1922638

专业的SQL Server、MySQL数据库同步软件

图1 MySql半同步过程

？

图1描述了MySQL Binlog半同步过程。等待ACK是半同步的关键步骤。主设备将Binlog发送到从设备后，它需要等待从设备ACK。主机在成功接收到ACK以将数据持久保存到存储之前，不会执行引擎提交。有关详细信息，请参阅:

？

MySQL启动时，将跳过Wait ACK进程，从而直接执行Engine Commit。有关详细信息，请参阅:

？

下面简单分析一下MySQL数据在Master和Slave之间是否可以保持一致。讨论基于每台机器的数据最终是否一致。以下分析仅适用于半同步复制，并且假定半同步故障不会退化为异步复制。

？

图2当主服务器重新启动时，将执行EngineCommit，并将Binlog再次复制到从属服务器

？

当主服务器重新启动时，执行EngineCommit。从站重新连接到主站，Binlog重新启动复制，然后从站数据与主站一致。如图2所示。

？

因此，在MySql5.7的情况下，方案2.2可以保证Master和Slave之间的数据一致性。但是，在MySQL 5.6和更早版本中，方案2.2无法保证数据的一致性。有关详细信息，请参阅:

？

数据已被复制到至少一个从站，这与旧主站的数据一致。

？

？

场景3.2.1

在旧的主崩溃期间，Binlog无法发送，并且未复制到任何从站。

图3机器A重新启动提交事务X。机器A/B数据不一致。

？

？

图4机器B接收到事务X的重试请求(事务X”)，并将其复制到机器A。

机器A/B数据可能不一致。

？

假设计算机A是旧的主服务器，则在执行事务X时，复制失败并崩溃。然后，机器B成为新的主机。机器A重新启动时，将执行Engine Commit，并提交事务X。此时，机器A和机器B的数据一致性被破坏。两台机器上的数据可能不一致。如图3，图4所示。

？

数据不一致的原因是，机器A在重新启动时会在PendingBinlog上执行引擎提交。在切换主机的情况下，只能通过回滚PendingBinlog来解决。

？

？

MySQL半同步插件的维护者也提到了类似的想法:

？

场景3.2.2

在旧的主崩溃期间，已成功发送Binlog，但尚未执行引擎提交。

？

图6机器A重新启动并立即执行Engine Commit，数据是一致的

？

假设机器A是旧的主服务器，执行事务X时执行提交前崩溃，但是机器B接收到事务X。然后机器B成为新的主服务器。

？

机器A重新启动时，执行Engine Commit to PendingBinlog。成功执行后，机器A的数据是机器B的子集。这时，机器A可以从机器B提取最新数据。可以从这两个机器中任意提取另一台从属机器C。

？

从图6可以看出，当机器A发生故障时，TransactionX已被复制到一个从属服务器，并且Commit Transaction X被立即重新启动，因此可以确保从属服务器和主服务器的数据一致。

图7两台机器发生故障，主交换机可能会丢失数据

？

上面的讨论基于这样的事实，即具有最新数据的从站和主站不能一起失败。当两台计算机一起出现故障时，主交换机将导致数据丢失。如图7所示。

？

对于较小的群集(计算机数小于或等于3)，当两台计算机一起出现故障时，可以认为该群集不再提供服务(半同步复制无法工作)。

？

对于较大的群集(计算机数量大于3)，当两台计算机一起出现故障并且无法知道两台计算机的数据状态时，群集将无法提供服务(无法确认从站是否具有最新数据)包含在故障机器中)。因此，对于较大的群集，通常会增加等待ACK的半同步复制的数量，因此，在发生上述情况时，仍可以执行主切换(无故障的机器，其中有最新数据的机器)。

？

增加ACK的等待数量可以解决数据丢失的问题，但同时也给数据回滚带来了困难。

？

图8

？

如图8所示。假定MySQL群集中有5台计算机，则半同步复制需要等待2个从属服务器的ACK。机器A是旧的Master。在等待ACK阶段，机器B收到Binlog后，机器A和机器B崩溃或同时被隔离，从而导致Binlog复制失败。根据方案3.2.1的分析，在机器C成为主机之后，机器A和机器B需要回滚其数据才能还原服务。但是，很难将数据回滚到从站。如果回滚失败，将存在数据不一致。

？

对于较小的集群，回滚PendingBinlog更容易实现。但是对于较大的群集，回滚PendingBinlog本身是一个未解决的问题。

？

MySQL主切换问题

在MySQL灾难恢复中，如何切换Master也是一个问题。

一个简单的Master切换步骤:

1.？暂停上级大师

2.？开始新的大师

3.？将MySQLClient的主节点更改为指向IP

？

有几个问题:

1.？当Master被隔离后，如何将其更改为Slave

解决方案:您可以修改MySQL代码并使用Zookeeper和其他外部辅助服务来自动维护Master的状态，从而解决Master隔离后无法操作的问题。

？

2.如何使用最新的Binlog数据定位MySQL

解决方案:您可以手动或使用外部工具检查集群中每个MySQL的数据。但是，当无法访问故障机器时，就无法定位。

？

3.？如何回滚数据

解决方案:您可以通过操作和维护来执行手动操作。

？

4.如何同时更改MySQLClient的主指针IP

不可能同时将所有MySQLClient主节点更改为指向IP，因为不可能同时操作所有计算机。

？

不可能同时将所有MySQLClient的主控点更改为IP，从而导致某些客户端向旧的Master发送请求，即多个Master同时服务。在使用半同步复制的情况下，多个MySQL无法同时知道主服务器的下落，因此数据可能不一致。

？

图9

图10

？

假设机器A是旧的主机，机器B是新的主机，并且机器C在收到主机更换通知之前仍将Binlog复制到机器A。用户1在主交换机之前已连接到机器A，并继续写入数据。主交换机切换后，User2开始将数据写入机器B。由于机器A可以将数据复制到机器C，机器B可以将数据复制到机器A，因此机器A和机器B都可以成功写入。如图9所示。

？

由于机器A和机器B同时写入数据，因此无法保证数据的一致性。如图10所示。

？

从以上分析可以看出，MySQL的半同步复制和Master交换存在一些缺陷。数据复制存在回滚问题，Master交换存在多主问题。只有解决这两个主要问题，数据才能实现。保证MySQL群集的一致性。