Page Comparison

...

• Both node’s current UUIDs are empty
  If both Current UUIDs are detected as empty, this is usually the case with new resource configuration and synchronization has never started. Synchronization does not proceed automatically here and you must start synchronization manually.

• the Current UUID of one node is empty
  If the current UUID of the other node is empty and it detects that it is not, this is usually the case when a full synchronization was attempted immediately from the newly configured resource, and the local node was selected as the source of synchronization. bsr internally sets all used area bits of the on-disk sync bitmap, and then start syncing as source. In the opposite case (when the local UUID is empty and the opponent is not empty) bsr will go through the same procedure, but only the local node is synchronized to the target.

• When both node’s current UUIDs are the same
  If your current UUID and your partner's UUID are not empty and are the same, this usually happens when you are disconnected in the secondary role and there is no promotion to any node during disconnected. Synchronization is not required and synchronization is not in progress.

• Bitmap UUID matches the current UUID of the other node
  If Bitmap UUID is the same as peer's Current UUID and peer's Bitmap UUID is empty, then this is normal and a failure occurs when local are in the Secondary role and promoted to the Primary role. This means that the peer node has never been Primary and has been working with the same data generation until then. bsr sets the local node as the synchronization source and prepares it for background resynchronization. Conversely, if the local node's Bitmap UUID is empty, and the peer's Bitmap is equal to its Current UUID, this is also normal and occurred after the local node failed. bsr sets the local node as the synchronization target and prepares for background resynchronization.

• Current UUID matches the historical UUID of the peer node
  If your Current UUID matches the Historical UUID of the other node, it means the following. While two data sets share a common previous generation content, it means that the other node has the latest data, but the Bitmap information cannot be used because it is from the past. Therefore, normal synchronization may not be enough. In this case, bsr marks the entire device out-of-sync and attempts a full background resynchronization by making the local node a synchronization target. Conversely, if there is a case in which the historical UUID of the local node matches the peer’s Current UUID, the local node becomes the synchronization source, and the same procedure is performed otherwise.

• Bitmap UUID matches, Current UUID does not match
  If your Current UUID is different from peer's Current UUID and the Bitmap UUID matches, then a split-brain has occurred. Both nodes are left disconnected and the administrator must manually resolve the split brain situation unless auto-resolve is enabled.If both Current/Bitmap UUID are mismatched
  If Current and Bitmap UUIDs are different from each other's UUID, this is a split brain situation that is not related to the previous creation. Therefore, even if automatic recovery is set, it has no meaning. The bsr is disconnected and becomes StandAlone, and the split brain situation must be resolved by the administrator

• Neither current nor bitmap UUIDs match, but Historical UUIDs match The local node detects that its current UUID differs from the peer’s current UUID, and that the bitmap UUID’s do not match, but historical UUID match. This is split brain with unrelated ancestor generations, thus auto-recovery strategies, even if configured, are moot. DRBD disconnects and waits for manual split brain resolution.

• If none of the UUIDs match
  Finally, if there is no match in the GI tuples of the two nodes, it disconnects with a warning that it is irrelevant data. This is a safety measure in case you are connecting between nodes that are not related at all.

...