磁盘损坏

    1、detach resource

        如果在resource的disk配置项中配置了on_io_error为pass_on的话，那么drbd在遇到磁盘损坏后不会自己detach底层设备。也就是说需要我们手动执行detach的命令（drbdadm detach resource_name），然后再查看当前各节点的ds信息。可以通过cat /proc/drbd来查看，也可以通过专有命令来查看：drbdadm dstat resource_name。当发现损坏的那方已经是Diskless后，即可。如果我们没有配置on_io_error或者配置成detach的话，那么上面的操作将会由自动进行。

        另外，如果磁盘损坏的节点是当前主节点，那么我们需要进行节点切换的操作后再进行上面的操作。

    2、更换磁盘

        当detach了resource之后，就是更换磁盘了。如果我们使用的是internal的meta-data，那么在换好磁盘后，只需要重新创建mata-data（drbdadm create-md resource_name），再将resource attach上（drbdadm attach resource_name），然后drbd就会马上开始从当前primary节点到本节点的re-synchronisation。数据同步的实时状况可以通过 /proc/drbd文件的内容获得。

        不过，如果我们使用的不是internal的meta-data保存方式，也就是说我们的meta-data是保存在resource之外的地方的。那么我们在完成上面的操作（重建meta-data）之后，还需要进行一项操作来触发re-synchnorisation，所需命令为：drbdadm invalidate resource_name 。

节点crash（或计划内维护）

    1、secondary节点

        如果是secondary接待你crash，那么primary将临时性的与secondary断开连接，cs状态应该会变成WFConnection，也就是等待连接的状态。这时候primary会继续对外提供服务，并在meta-data里面记录下从失去secondary连接后所有变化过的block的信息。当secondary重新启动并连接上primary后，primary –> secondary的re-synchnorisation会自动开始。不过在re-synchnorisation过程中，primary和secondary的数据是不一致状态的。也就是说，如果这个时候primary节点也crash了的话，secondary是没办法切换成primary的。也就是说，如果没有其他备份的话，将丢失所有数据。

    2、primary节点

        一般情况下，primary的crash和secondary的crash所带来的影响对drbd来说基本上是差不多的。唯一的区别就是需要多操作一步将secondary节点switch成primary节点先对外提供服务。这个switch的过程drbd自己是不会完成的，需要我们人为干预进行一些操作才能完成。当crash的原primary节点修复并重新启动连接到现在的primary后，会以secondary存在，并开始re-synchnorisation这段时间变化的数据。

        在primary节点crash的情况下，drbd可以保证同步到原secondary的数据的一致性，这样就避免了当primary节点crash之后，secondary因为数据的不一致性而无法wcitch成primary或者即使切换成primary后因为不一致的数据无法提供正常的服务的问题。

    3、节点永久性损坏（需要更换机器或重新安装相关软件的情况）

        当某一个节点因为硬件（或软件）的问题，导致某一节点已经无法再轻易修复并提供服务，也就是说我们所面对的是需要更换主机（或从OS层开始重新安装）的问题。在遇到这样的问题后，我们所需要做的是重新提供一台和原节点差不多的机器，重新开始安装os，安装相关软件，从现有整提供服务的节点上copy出drbd的配置文件（/etc/drbd.conf），创建meta-data信息，然后启动drbd服务，以一个secondary的身份连接到现有的primary上面，后面就会自动开始re-synchnorisation。

split brain的处理

    split brain实际上是指在某种情况下，造成drbd的两个节点断开了连接，都以primary的身份来运行。当drbd某primary节点连接对方节点准备发送信息的时候如果发现对方也是primary状态，那么会会立刻自行断开连接，并认定当前已经发生split brain了，这时候他会在系统日志中记录以下信息：“Split-Brain detected,dropping connection!”当发生split brain之后，如果查看连接状态，其中至少会有一个是StandAlone状态，另外一个可能也是StandAlone（如果是同时发现split brain状态），也有可能是WFConnection的状态。

    如果我们在配置文件中配置了自动解决split brain（好像linbit不推荐这样做），drbd会自行解决split brain问题，具体解决策略是根据配置中的设置来进行的。

    如果没有配置split brain自动解决方案，我们可以手动解决。首先我们必须要确定哪一边应该作为解决问题后的primary，一旦确定好这一点，那么我们同时也就确定接受丢失在split brain之后另外一个节点上面所做的所有数据变更了。当这些确定下来后，我们就可以通过以下操作来恢复了：

    a、首先在确定要作为secondary的节点上面切换成secondary并放弃该资源的数据：

        drbdadm secondary resource_name

        drbdadm — –discard-my-data connect resource_name

    b、在要作为primary的节点重新连接secondary（如果这个节点当前的连接状态为WFConnection的话，可以省略）

        drbdadm connect resource_name

    当作完这些动作之后，从新的primary到secondary的re-synchnorisation会自动开始。