服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

DRBD双重主要再访

这是一个旧的数据,在双主模式下使用非集群感知的文件系统(如Linux上的带有DRBD的ext4)是不可能的。 例如,如Linbit在他们的手册“Dual Primary – Think twice”中所述: DRBD将从节点A到节点B的更改复制到另一个方向。 它改变了物理存储设备的内容。 但是 – 正如DRBD所在 在所提到的Ext4文件系统下,物理磁盘上的文件系统 节点A不会注意到来自节点B的更改(反之亦然)。 这个过程被称为并发写入。 从现在开始,实际的内容 的存储设备不同于它认为应该是的文件系统。 文件系统已损坏。“ 我的问题是 – 这是为什么? 因为,如果该文件系统的元数据存储在相同的DRBD设备上,则上述任何变化都将在两个DRBD节点之间同步,因此两端的文件系统(包括数据+元数据,不是吗?)完全同步。 确实,节点1写的节点1被节点2覆盖了,但是如果我在节点1上发出“dir”命令,我会看到还有另一个文件,而不是刚刚复制的节点1。 简单的共享文件夹(如Windows CIFS共享)也会发生同样的情况。 这不会导致文件系统损坏。 那么问题在哪里? 为什么大家都说文件系统会损坏? 这是否意味着ext4文件系统不会将元数据存储在实际设备本身上,而是将其存储在其他位置,例如在根文件系统中? 根据我所能读到的ext4 FS的内部情况,情况并非如此。 (我不得不说,我没有深入ext4的细节)。 但它应该或多或less是这样的: Node1将新文件写入到块34098(并更新目录条目): 节点1 – 目录条目:/data/myfile1.txt 34098 —–> 34098块包含:myfile1.txt 在“同一时间”,Node2写入以下内容到块34098.它不能在“同一时间”,所以我们假设它是当DRBD刚刚完成同步以上。 节点2 – 目录条目:/data/other.txt 34098 —–> 34098块包含:other.txt DRBD现在应该再次将块34098同步回到节点1,目录条目和块34098。 除了将文件“other.txt”写入块34098之外,node2上的文件系统还将更新包含指向块34098的目录项(这只是另一个文件)的块。所以它应该始终同步,否则?