linux – 双主OCFS2 DRBD遇到了裂脑.在这种情况下,恢复总是手动的吗？

概述我有两个网络服务器,每个都有一个磁盘连接.在“双主”模式下使用drbd(2：8.3.13-1.1ubuntu1)在它们之间同步该磁盘,并在此顶部运行ocfs2(1.6.4-1ubuntu1)作为集群文件系统.节点在专用网络192.168.3.0/24上进行通信.在大多数情况下,这是稳定的,并且运作良好. 昨晚,似乎有网络中断.这导致了一个裂脑情况,其中node01保留在Standalone和Pri 我有两个网络服务器,每个都有一个磁盘连接.在“双主”模式下使用drbd(2：8.3.13-1.1ubuntu1)在它们之间同步该磁盘,并在此顶部运行ocfs2(1.6.4-1ubuntu1)作为集群文件系统.节点在专用网络192.168.3.0/24上进行通信.在大多数情况下,这是稳定的,并且运作良好.

昨晚,似乎有网络中断.这导致了一个裂脑情况,其中node01保留在Standalone和Primary中,而node02保留在WFConnection和primary中.恢复是今天早上分散两个文件系统的手动过程,决定node01应该是权威的,将node02放入secondary,然后在每个节点上发出drbdadm connect命令.在此之后重新安装文件系统,我们将重新启动并运行.

我的问题是：这种类型的停机总是需要手动解决吗？或者有哪些方法可以使这个过程自动化？我的理解是,drbd应该尝试在大脑分裂的情况下变得聪明,以确定哪个节点应该成为主要节点和次要节点.看起来在这种情况下,一个简单的网络中断都留在了主要的,我的配置只是说’断开’.查看日志,我觉得有趣的是,他们似乎都同意node02应该是SyncSource,但是在查看rsync日志时,实际上node01具有最新的更改.同样有趣的是node01上的一行说明’我将成为SyncTarget,但我是主要的！’.对我来说,看起来drbd试图解决这个问题,但由于某种原因失败了.

有更好的方法吗？

r0的配置是这样的：

resource r0 {    Meta-disk internal;    device /dev/drbd0;    disk /dev/xvda2;    syncer { rate 1000M; }    net {        #We're running ocfs2,so two primarIEs desirable.        allow-two-primarIEs;        after-sb-0pri discard-zero-changes;        after-sb-1pri discard-secondary;        after-sb-2pri disconnect;    }    handlers{        before-resync-target "/sbin/drbdsetup $DRBD_MInor secondary";        split-brain "/usr/lib/drbd/notify-split-brain.sh root";    }    startup { become-primary-on both; }    on node02 { address 192.168.3.8:7789; }    on node01 { address 192.168.3.1:7789; }}

我还将kern.log文件放在pastebin上：

Node01：http://pastebin.com/gi1HPtut

Node02：http://pastebin.com/4XSCDQdC

解决方法 恕我直言,你已经为DRBD选择了最好的SB政策.因此,在您的情况下,必须在文件系统的同一部分(即DRBD块)上进行更改.

所以在那种情况下 – 是的 – 你必须手动解决这个问题.

出现的问题是为什么这些并发访问会发生？

你应该调查那个方向.如果网络出现故障,一方应该无法访问,因此“放弃零更改”应该有所帮助 – 但事实并非如此.

除此之外,您应该通过两个或更多个独立的网络连接来防止分裂大脑.我总是在我的集群中使用其中的三个.

总结

以上是内存溢出为你收集整理的linux – 双主OCFS2 DRBD遇到了裂脑.在这种情况下,恢复总是手动的吗？全部内容，希望文章能够帮你解决linux – 双主OCFS2 DRBD遇到了裂脑.在这种情况下,恢复总是手动的吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。