Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

According to DRBD documentation of replication mode.

Protocol C. Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. Refer http://www.drbd.org/users-guide/s-replication-protocols.html

So is there any chances that split brain occurs ? If I am using protocol C there is no chances that data will be partially written on one of the disk.

Edit:

Is there any chances of data corruption/lost/mismatch of data b/w two nodes ?

This is a potentially harmful state, as it implies that modifications to the data might have been made on either node, without having been replicated to the peer. Thus, it is likely in this situation that two diverging sets of data have been created, which cannot be trivially merged. http://www.drbd.org/users-guide/s-split-brain-notification-and-recovery.html

share|improve this question

2 Answers 2

Split-brain in a cluster has nothing to do with data integrity, data integrity issues can be a consequence of a split-brain situation:

My Defintion of a SB:

The (redundant) replication network is disconnected, not more, not less.

So the answer to your question is: Yes a SB can always occur.

Wit Protocol C in DRBD you effectively protect yourself from suffering data loss/ corruption because whenever the split brain occurs, you can be sure that both cluster members are in sync.

share|improve this answer
    
I am only concern about: "This is a potentially harmful state, as it implies that modifications to the data might have been made on either node, without having been replicated to the peer. Thus, it is likely in this situation that two diverging sets of data have been created, which cannot be trivially merged.". Any chances for this with protocol C ? –  Vivek Goel Jan 17 at 11:09
    
This is a question of what happens AFTER a split brain occurs and this is controlled by DRDB itself (you can instruct it how to react upon a SB) OR by a cluster resource manager such as pacemaker which you also can instruct how to deal with it. So whether it is harmful or not depends on your very setup. –  vanthome Jan 17 at 11:16
    
I think there is some problem with my explaining or your understanding. Let's try again. I know split brain can happen with protocol C. So what I don't know. Is it going to cause any data inconsistency ? As according to protocol C write will complete only if written on both node. So it should not result in any data corruption/mismatch of data. –  Vivek Goel Jan 17 at 11:31
    
No, this assumption is wrong and that's why the docs you refer to say "potentiallty". Acually I gave the answer in my previous POST: The question can only be answered with knowing your current setup. I examplify: If you have no cluster manager/ fencing in place and configured DRBD to continue after split brain and both servers are still accessible and use, then you will be left with inconsistent data no matter what service you run. –  vanthome Jan 17 at 11:37

Yes, you can produce split-brains pretty easy with protocol C.

Possibility 1: You use Protocol C with a primary/primary constellation and write to the same file/block on both sides.

Possibility 2: Protocol C, the cluster splits, each side thinks it is the sole survivor and goes into primary/unknown and there are writes on both sides to the same file(s) and/or blocks.

This is where you should have good SB-rules in place. I prefer:

after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.