ha fencing

http://space.itpub.net/133735/viewspace-743921

做了一轮ha 的测试

如果我们近似同时的在连个node ，修改网络配置

ifconigure  eth0 x.x.x.x  up

两个节点各配置不同的ip，会导致系统发上 脑裂 。
两个节点相互认为对方损坏了。 状态为 认为对方 UNCLEAN (OFFLINE)

然后就开始相互的重启对方的主机，就这样死循环下去了。



这个时候是比较难处理的，资源在两个节点间不停的来回切换，对 数据库 类应用来说是不允许的。

需要从这个状态中 恢复 ，也比较费时。

先关闭HA 集群的开机自启动。
然后手工重启两个几点，然后手工启动ha服务。可以让集群恢复正常状态。这期间可能已经发生了多次来回的切换，导致数据库损坏。

另个方式我们设置 fence  设备的默认动作为poweroff ，也就是说无论什么情况下，一旦发生问题，就直接poweroff 关闭对端的主机了。这个时候，就跟我们目前的单机服务差不多了。
在上面 提到的情况下， 因为我们已经修改了两个节点的ip设置，所以正在服务的备用节点的网络配置已经改变了，但是可以提供完整的集群服务。

这个例子里，我通过重启网络来恢复了网络配置，会导致ClusterIP 和pg 数据库发生一次重启动。 这个情况，在我们的线上应该不会发生，没有道理去修改网卡的配置。

在设置了fence设备的动作为poweroff 的时候，ha设为开机自启动，当吧已经关机的机器人工开起来后，如果正在服务的机器的修改后的ip没有改回原来的，会导致俄发生一次资源切换。这个也是我们不希望的。

如果不是通过修改ip 来触发脑裂，
或者两边的ip 不变的情况下发生了底层心跳连接断开，应该不会发生我上面描述的情况。

比较保险的做法是：

设置fence 设备的actio 默认为poweroff ，关闭HA  软件 的开机自启动。

这样一旦发生了故障，我们可以确保只发生一次故障切换。

我们的保障只允许发生一次，跟我们 mysql  的现行的HA 的策略是一致的，只支撑一次故障切换。

如果连续的发生故障，导致从库再切为主库，也坏掉了，就没有系统在服务了，
这个情况，我们希望转为人工处理。