不久前的一次机房网络故障，再一次对我们在Heartbeat+DRBD+MySQL数据库架构运维水平的一个考验，之前不止一次的测试与线上部署，还有之后大言不惭的关于该架构组件的所谓深入理解，在这一次不经意的意外面前又是“很囧”的收场，慌张呀！这次断网导致H-D-M全线异常，真是千载难逢，都让我们赶上啦lol: 下面就把这次的小幸运小幸福和大家分享下，以下是按照问题处理的先后顺序依次讲述。
– MySQL Replication同步异常
当发生网络故障一个小时后，从库io_thread和主库的连接被中断，抛出错误提示：[ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)，没想到竟遇到了一个古董级的Bug，有点喜出望外了（心想，我也能遇到bug）。最后解决办法，只能拿备份重新做一遍主从。后来，好奇想查查，究竟是怎么导致这个问题，竟发现，从库relay log中的记录比主库binlog中的记录多了2条insert和1条update（0_0!!!…不合逻辑呀？！！）。
– DRBD状态异常
处理完数据库同步问题后，当时并没有去查看DRBD的状态，直到周一才发现出问题了，简单地通过命令cat /proc/drbd就可以查看，DRBD的状态是否正常。查看/var/log/messages知道网络故障导致DRBD发生脑裂，彼此都认为对方已经死了，然后自己都将角色作为Primary，并积极获取资源，当时的两端的连接状态都为StandAlone，角色都为Primary。在发生脑裂不久后原active node被heartbeat强制将系统重启，最后，原active node角色变为Secondary/Unknown，原standby node角色依然是脑裂时的Primary/Unknown，两端的连接状态，分别为WFConnection和StandAlone。解决方法如下：
Step 1 – On New Secondary:
# service heartbeat stop
# service drbd stop
# drbdadm create-md r0
# service drbd start
# service heartbeat start
Step 2 – On New Primary:
# service drbd reload
之后就进入漫长数据同步阶段，重新将Primary上的数据块文件拷贝到Secondary上，最后完成同步。
– Heartbeat通信异常
通过查看/var/log/ha-dug日志，发现在出现网络故障后4分钟内，Heartbeat服务在active node与standby […]