drbd+pacemaker实现数据库高可用的问题总结

1.drbd的脑裂问题。

drbd脑裂是指当两个节点（假设只有两个节点）因为网络问题或某一个节点的主机故障等问题，造成数据不能实时同步，就会产生脑裂，drbd脑裂在drbd配置文件的net部分有三个场景，并分别有相应的自动处理策略：

after-sb-0pri：这个场景是因为网络故障等原因，现在有0个primary节点，即两个节点都处于从状态，此时两个节点可能都有了新数据（这时候是很糟糕的，两个节点都有数据了，但又不能合并，必须确定一个主节点，并让另一个节点以此为准同步数据），那以谁的数据为准呢？必须要有所取舍了，此时的处理策略有如下几种：

disconnect：直接退出集群，即两个节点均不再参与数据同步，成为孤立节点
discard-younger-primary：丢弃最先的主节点数据，也即是最后成为主节点的节点为新的主节点
discard-least-changes：谁的数据改变最少则谁被抛弃，也即是谁的改变多以谁为主节点
discard-zero-changes：没有改变数据的节点被抛弃，也就是说如果某个节点没有改变数据，说明这个节点发生了故障，要作为从节点。

after-sb-1pri：这个场景是发生脑裂后，现在有1个主节点，另一个节点要么丢弃现有的数据，并以另一个节点为主进行数据同步，要么采用别的办法，如disconnect，策略有如下几种：

disconnect：和上面的解释相同，直接退出drbd集群，不再参与数据同步
consensus：和after-sb-0pri的处理策略相同
call-pri-lost-after-sb：也和after-sb-0pri的处理策略相同，但如果有配置handler脚本的话执行脚本进行处理
discard-secondary：把此节点直接当做脑裂受害者，把另一个节点当做主节点进行数据同步，注意，如果此节点有新数据的话也直接丢弃了。

after-sb-2pri：这个场景是有两个节点都是主节点的情况，处理策略和上面的一个差不多，只是没用了discard-secondary 和 consensus策略，因为两个都是主节点了，就没用所谓的丢弃从节点的策略。

介绍完上面的三种策略，我们就要根据场景来选择了，比如数据库同步场景，我们想让数据最安全，当发生网络故障、某一个节点主机故障等情况，要做到不丢数据，最保险的做法是三个节点都采用disconnect，即直接退出集群不再同步，不丢弃任何数据，但集群切换后，需要手工修复，即要dba人工确定哪个节点的数据时主节点，并把另一个节点作为从节点进行数据同步（方法见 这里）。配置如下：

net {

}

如果数据不是很重要，不涉及金融数据，想让某台节点故障后自动进行数据同步，可以采用如下策略：

这样当一台机器挂掉后另一台启动后可以自动以另一台为主节点进行数据同步而不需要手工数据同步。

2.和pacemaker配合时的问题

使用pacemaker来做集群故障切换时，会遇到另一个问题，当两个节点发生脑裂后，如现在两个都是从节点，且两个从节点的数据目前不处于同步状态，pacemaker也会切换的，这时候会因为pacemaker启动了陈旧的数据而造成数据不一致，这个场景可能发生在这种情况：

1.两台主备节点正常运行，数据处于drbd同步状态

2.一台主节点挂掉了，从节点接替了主节点，然后有新数据进来了，这时主节点处于离线状态，新数据现在只在一个节点上有，这时就出现不一致数据状态

3.这时从节点也挂掉了

4.这时原来的主节点修复好了，这时pacemaker会启动主节点的资源，这时又一部分新数据进来，到了原来的主节点上

5.这时原来的从节点修复好了，这时候就两个节点都有一部分新数据，造成了数据不一致

为了避免这种情况，需要采用如下办法：

在drbd的disk配置部分，加入如下配置：