Chinaunix首页 | 论坛 | 博客
  • 博客访问: 50252
  • 博文数量: 9
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 87
  • 用 户 组: 普通用户
  • 注册时间: 2012-03-04 23:05
文章分类

全部博文(9)

文章存档

2015年(7)

2014年(2)

我的朋友

分类: LINUX

2015-06-14 23:05:57

关于DRBD v8.3的同步机制 (2012-09-18 14:14:04)转载
标签: drbd ext3 linux redundancy 双机 分类: drbd
DRBD 将其备份的数据的更新变化过程比拟成人类世代繁衍的这么一个过程。每个时点同一个双机的DRBD的两个节点上的数据都来自于同一份原始数据,我们可认为这个时点上两分数据源于同一祖先。主备节点的DRBD都会用一个叫作GI(Generation ID)的标识符来标识当前的数据是哪个世代的,同样也会记录最近两个数据祖先的GI用于追朔当前数据的历史来源。DRBD可以据此来判断两个节点是否是属于同一个双机。因为同一个双机的两份数据应该是从同一个祖先而来。DRBD 内部用GI来:
1. 判断两个节点是否是属于同一个双机。
2. 在需要同步时确定同步的方向。
3. 确定否触发一个全盘同步还是触发一个部分同步。
4. 确定裂脑。

当出现下列情形里DRBD会生成一个新的GI,用来标识新一代的数据:
1. 第一次全同步的时候。
2. 一个处理Disconnected的资源变成Primary的时候。
3. 一个Primary的资源变成Disconnected的时候。


因此可以得出这样的结论:
只要一个DRBD资源处于Connected的状态,并且磁盘的状态为UpToDate,那么此DRBD资源在两个节点上的GI一定是一样的。此结论反过来也同样成立。
每个GI是一个8字节的二进制数据,是一个全局唯一标识符(UUID)。
DRBD 在本地Meta数据中保存着一个包含四个UUID的UUID组来记录数据的更新变化情况,DRBD根据对比主备两节点上的的两份UUID组中的四个UUID来判断采取什么样的同步策略。

UUID组中包含的四个UUID分别是:
1. Current UUID(C-UUID)。
2. Bitmap UUID(B-UUID)。
3. 上一代数据的UUID(H1-UUID)。
4. 最近第二代数据的UUID(H2-UUID)。即上一代数据的上一代数据的UUID。

那么UUID是怎么变化的呢?UUID发生变化的场景大致有以下三种:
1. 断开连接时
2. 开始同步时
3. 同步完成时

断开连接时UUID的变化规则:
1. 主节点生成新的C-UUID。
2. 主节点的老C-UUID成为新的B-UUID。
3. 主节点的H1-UUID和H2-UUID保持不变。
4. 备节点的UUID组保持不变。

开始同步时UUID的变化规则
在DRBD发起一次同步时,UUID会做如下变化:
1. 源节点的C-UUID保持不变。
2. 源节点的B-UUID成为源节点的H1-UUID.
3. 源节点生成一个新的B-UUID。
4. 源节点新生成的B-UUID成为目标节点的C-UUID。
5. 目标节点的B-UUID,H1-UUID和H2-UUID保持不变。

在DRBD同步结束时UUID会做如下变化:
1. 源节点的C-UUID保持不变。
2. 源节点的B-UUID成为源节点的H1-UUID。而老的H1-UUID则成为源节点的H2-UUID.
3. 源节点的B-UUID被清空,即B-UUID的8字节全部为0。
4. 目标节点的整个UUID组都被替换成源节点的UUID组。

当两个节点建立连接的时候,会首先把本地的UUID组和对方的UUID组进行比对,然后根据比对的结果采取相应的操作。以下是可能的几种结果:

1. 两个节点的C-UUID都为空。这通常是一个新配的DRBD资源的初始状态。这个时候需要人为地触发初始全盘同步。

2. 其中一节点的C-UUID为空。如果本节点发现对方的C-UUID为空,而本地的C-UUID非空。这通常发生在新配置的DRBD资源的初始全盘同步被触发(本节点为同步的源节点)后但在同步完成前断掉连接,再次连接的时候就会出现这种情况。这个时候DRBD会将磁盘上的同步位图(sync bitmap)全部置位(意思是需要一次全同步)并且将本节点选作同步源发起一次全同步。

3. 两节点的C-UUID非空并且相等。这种情况一般是:上一次断开连接时两节点均为secondary状态,并且处理数据一致状态。并且在上次断开连接之后两节点都未被提为primary状态。此时不会触同步,因为两边的数据是一致的,没有必要进行同步。

4. 本节点的B-UUID和对方的C-UUID相同。本节点发现本节点的B-UUID和对方的C-UUID相同并且对方的B-UUID为空。当两节点处理UpToDate状态,对方节点作为secondary状态断开连接,本节点断开时为Primary状态或断开后成为Primary状态。两节点再次连接时就会出现这种情况。此时DRBD会选择本节点为源进行一次同步。

5. 本节点的C-UUID与对方的H1-UUID或H2-UUID相同。这暗示了两份数据都来自于同一份数据,有一个共同的祖先。并且本节点拥有最新的数据(UpToDate),保存在本节点的bitmap中的信息已经过时(out of date)不能使用。这个时候DRBD会将本节点作为同步源触发一次全盘同步。

6. 双方B-UUID相同,但C-UUID不相同。这是split-brain(裂脑)的情况,但两份数据都来自同一代数据。这时会采用自动恢复策略进行自动恢复如果配置了自动恢复策略。否则如果没有配置自动恢复策略,则保持断开连接等待手工恢复。

7. 双方的B-UUID和C-UUID都不相同。这也是split-brain(裂脑)的一种情况,但两份数据来自两代不同的数据。这种情况下,裂脑自动恢复策略不起作用。将保持断开连接等待手工恢复。

8. UUID组中的四个UUID都不相同。在这种情况下,DRBD打出一条警告日志说是两份DRBD数据是"unrelated data", 并保持断开连接,等待手工操作。这个策略可以避免两个不同cluster的节点因偶然连接而遭到数据破坏。
阅读(2771) | 评论(0) | 转发(0) |
0

上一篇:块设备的概念(二)

下一篇:没有了

给主人留下些什么吧!~~