免责声明:以下博客并不试图提供一个解决方案对于脑裂情况,和提供的例子只是用于演示目的。不一致造成的。这些场景可能是更复杂的比显示的,所以不要使用以下示例作为一个完整的指南。

这些数据集这些是什么?

split - brain场景是两个数据集的结果(最初同步)失去同步的能力虽然可能继续接收摘要同期行和ids两边。这可能后果如数据损坏或数据不一致,每一方都不存在在另一边。

例如split - brain之前:

split - brain之后:

Node1:

Node2:

可以看出,在split - brain场景有很多节点之间的差异:

  • 客户行id = 2 Node2上被删除
  • 有一个“客户”表上插入在每个节点上,但插入的行重复id = 3
  • 有一个插入“Customer_product”表上的每个节点上与id = 2引用客户id = 3

试图合并将导致所有的行id碰撞和矛盾。

为什么会发生这些呢?

split - brain发生最典型的原因是当一个异步集群拓扑失去连通性和每个节点独立继续提供服务,但其他示例案例:

  • 奴隶节点复制停止,并与主多日不同步;然后主服务器发生故障时自动晋升到奴隶。当主服务器重新上线就会矛盾1)主会写道,没有复制到从2)奴隶会对主写道,不发生时离线。
  • 集群上,一些节点接收禁用/删除复制写道,造成数据不一致而到其他节点。
  • 新老服务器的系统迁移工作同时为不同的客户没有同步数据,并在某一时刻数据从旧服务器需要迁移到新服务器的关闭。

为什么很难同步split - brain场景吗?

split - brain场景下,有许多不一致,不能自动合并。如果恢复信息从一个节点到另一个就会失去后者节点上发生的变化,如果试图合并,出现很多问题,例如,上面的例子:

  • 会发生什么,从Node2删除客户id = 2 ?它应该保存或删除吗?
  • 插入的行id = 3应该是两个不同的行,或只有1行应该保留?为id = 3,在这种情况下,正确的值将是“汤姆”或“比尔”?
  • 引用表只有1的区别,但是合并行id = 2将参考parent_id = 3是模棱两可的

因为上面的,修复一个split - brain场景将取决于业务规则来决定哪些行保持/丢弃,将导致手动工作来决定每一个矛盾。

如何避免split - brain场景吗

当有网络问题,导致脑裂情况和根据上限定理,这是不可能的,以确保一致性和可用性,必须优先考虑哪一种类型。

在支持一致性的情况下,使用雷竞技下载官网Percona XtraDB集群允许主要组件(如果有的话)提供的数据,而非主组件拒绝操作。如果使用自动故障转移的解决方案如协调器,它应该配置,这样写只去一个节点,和促进奴隶只发生如果奴隶是目前最新的网络失败了。如果它是不可能保证数据一致性,然后节点应该拒绝工作。

的情况下的服务需要维护split - brain场景,会有矛盾,但是这可以避免重复的id是使用不同的auto_increment_increment和auto_increment_offset在每个服务器上,这样,例如,服务器id偶数和ids服务器B是奇数。

更新和删除必须通过案件得到解决。

你怎么解决一个split - brain场景?

正如前面所示,如果写发生在不同节点split - brain之后,合并的行以一致的方式是很困难的。程序手册和繁琐的行保持必须检查一个接一个地决定不一致性和标准应该基于业务逻辑。

如果只有一个节点收到写道(并提供所有必需的变量启用事先和二进制日志可用),有一种工具叫MySQL倒带可以帮助恢复的变化改变了节点相比,原节点。这个工具有一些局限性在官方文档上市但很有用的满足提供了需求。

如果两个(或更多)节点收到后split - brain写道,合并过程将更加复杂。高级程序如何解决矛盾将如下:

首先,两个数据库备份。然后确定哪些行是不同的两个节点在每个集群通过比较表。如果你有具有时间戳的表创建/版可能会大大有助于确定哪些行更新/插入后split - brain场景开始,否则最好是选择一个数据库作为源的真理,和其他工作来识别差异,而合并一个接一个的变化和根据业务规则。

可能的场景可能发生:

  • 如果一个行不存在于一个节点,但另一方面,这可能是一个删除。根据业务逻辑,决定保留或删除它。
  • 如果一行存在两个节点,但发生了更新和一些(但不是全部)列不同,使用业务逻辑和可用信息来选择哪一行。
  • 如果两行存在相同的id,但所有列不同,这可能是两个不同的插入(在每个节点上)和合并它们会碰撞。如果你决定节点2的行插入到真理的来源,您可能需要调整ids,例如添加一个巨大的数字(我当前id。e current_id + 100 k)。
  • 如果从Node2是一行插入到真理的来源和引用另一个行,仔细检查如果父行id是正确的,否则id可能是固定增加100 k,显示在上面的例子中,在这种情况下,你需要解决引用id。

合并后的数据和添加id, id可能有缺口导致浪费id,在这种情况下,倾销和重载表删除空白可能是个不错的主意。

结论

业务逻辑必须事先决定split - brain场景下如何反应——是否支持一致性和可用性通过比较失败的后果服务和数据合并后的成本和难度split - brain结束。