私有云如何部署数据库，尽可能地避免数据脑裂问题？

添加冗余的心跳线,例如双线条线。

尽量减少“裂脑”发生机会。

启用磁盘锁。

主从库分别部署在A，B两个机房做容灾，HA的两个节点也分别部署在两个机房。当A，B机房间发生网络故障，但是A，B机房自身正常时，两边的HA 都分别看见对端的实例节点放生故障，会将自己机房的实例提升为主库，那么此时如果两个机房都有流量进来，那么就可能导致数据库“双写“，也就是会发生所谓的“脑裂”问题。

首先，为了保证数据库数据的一致性，需要牺牲一定的可用性。通过上问的分析，可以发现，HA通过判断主备库与自己的心跳链接延迟来判断是否需要切换。因此，“脑裂”问题的出现最直接的表现就是心跳链接的延时表现为“无限大”。当HA检测到这种“无限大”的延迟后，不应该简单的做出切换主从库角色的决策，首先应该判断故障类型。如果节点之间网络畅通（通过网络测试获知网络畅通与否），则可以进行主从切换。根据上文的分析，这种切换不会导致数据的不一致。而如果节点直接网络不畅通（具体表现为被测试主机不回复网络探测请求），由于无法判断故障具体类型（主机崩溃或网络断开），因此此时不应该进行主从切换。需要人工介入排除故障。这样，在故障期间，数据库处于不可用状态，牺牲了一部分可用性。

当故障排除后，网络数据包可以流入主从数据库。由于之前的故障，主从数据库处于不一致状态。为解决故障导致的数据库不一致，需要在主备数据库读写过程与心跳链接中增加若干步骤。通过前文分析我们们可以知道，主数据库的写操作日志时间戳一定晚于从数据库的时间戳。此外，HA执行的健康检查策略要求主从数据库更新各自的心跳表。当故障恢复后，HA着手进行主从切换时，首先要比较两个数据库各自的操作日志，通过时间戳确定在故障发生前的主数据库，然后将从数据库同步到主数据库的状态。通过牺牲一定的可用性来保证数据库的一致性。