I saw your thread over it just now on the old forum. Sounds cool. Were you using an actual mysq cluster software? Sounds so. Maybe what you were experiencing was a bug or something. I wonder if it would work better. The only thing I dont like about samba and I believe windows does this as well with their cluster is that the locking table for file sharing is not carried over to the other node, so though clients have a true transparent failover with mysql, they still may have close and open programs that require a lock. IE, if you had dentrix, you would have to close it completly out and then open it again.
But I did notice that with the Distibuted File System running Domain mode, dentrix didnt have to reconnect, the locks were held on both servers.
And with vmware, a host gets completly rebooted so failover isnt very fast...
I want to test microsoft cluster next, but I havent... But so far, DRBD and MySQL and Samba, etc, may work well. I just havent tested it like hell. Its all about how to configure the split brain, which I was completly new too. DRBD 8x handles this differently in older versions.. and I think after doing some reading, that its better.
If server 1 and server 2 were in a node, and server1 was primary (running mysql and samba) and it failed, server 2 would take over and become primary. And when server1 was repaired, and came back online, it will sync its data with server2, but will still remain primary.
Ahh you know.. Read this and tell me what you think... I want someone to double check my logic...
I went with this. But its for an automatic recovery. Some people prefer to have a manual recovery.
What is a split brain with drbd?
DRBD detects split brain at the time connectivity becomes available again and the peer nodes exchange the initial DRBD protocol handshake. If DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection. The tell-tale sign of this is a message like the following appearing in the system log:
http://www.drbd.org/users-guide/s-confi ... avior.html
Automatic split brain recovery policies
In order to be able to enable and configure DRBD's automatic split brain recovery policies, you must understand that DRBD offers several configuration options for this purpose. DRBD applies its split brain recovery procedures based on the number of nodes in the Primary role at the time the split brain is detected. To that end, DRBD examines the following keywords, all found in the resource's net configuration section:
•after-sb-0pri. Split brain has just been detected, but at this time the resource is not in the Primary role on any host. For this option, DRBD understands the following keywords:
◦disconnect. Do not recover automatically, simply invoke the split-brain handler script (if configured), drop the connection and continue in disconnected mode.
◦discard-younger-primary. Discard and roll back the modifications made on the host which assumed the Primary role last.
◦discard-least-changes. Discard and roll back the modifications on the host where fewer changes occurred.
◦discard-zero-changes. If there is any host on which no changes occurred at all, simply apply all modifications made on the other and continue.
•after-sb-1pri. Split brain has just been detected, and at this time the resource is in the Primary role on one host. For this option, DRBD understands the following keywords:
◦disconnect. As with after-sb-0pri, simply invoke the split-brain handler script (if configured), drop the connection and continue in disconnected mode.
◦consensus. Apply the same recovery policies as specified in after-sb-0pri. If a split brain victim can be selected after applying these policies, automatically resolve. Otherwise, behave exactly as if disconnect were specified.
◦call-pri-lost-after-sb. Apply the recovery policies as specified in after-sb-0pri. If a split brain victim can be selected after applying these policies, invoke the pri-lost-after-sb handler on the victim node. This handler must be configured in the handlers section and is expected to forcibly remove the node from the cluster.
◦discard-secondary. Whichever host is currently in the Secondary role, make that host the split brain victim.
•after-sb-2pri. Split brain has just been detected, and at this time the resource is in the Primary role on both hosts. This option accepts the same keywords as after-sb-1pri except, of course, discard-secondary
This is what I have in my config file as directed from that link. And I had to make sure that this is truly what I want to be as there are many options, and this seems to do what I would want. But its a lot to wrap my mind around because I am not used to thinking this way.... =)
after-sb-0pri discard-zero-changes
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;