one question remains: what you got is a master - "master slave" - multiple slaves setup, right?
Or did you really set up a multi-master replication? If so, how?
By the way, thank you for sharing your setup, it is very helpful for us (as we are looking for a high-availability solution for mysql (preferably a multi-master cluster)) but the last bits of mist also need to be lifted!
So, basically, if I got you right, in your case no app can choose randomly whether to update master1 or master2: it's either master1 __or__ master2 for __all__ slaves?
In case of error on master1 you fail over to master2 which from now on is the only master available for updates?
Thank you again for your insights.
Kind regards,
Frank.Andrew Braithwaite schrieb:
Hi,
So how does this bit work? If one master falls over and slaves move to master two, how do you rebuild master one without downtime? Don't the slaves try and use Master 1 as soon as it's back online even though its data is out of sync?
If master 1 fails and the slaves move to master 2, then they effectively swap roles as primary and secondary masters and the directive is issued to the webservers to connect in the reverse order. Yes, master 1 will be offline until it is rebuilt and will join again in the secondary role. The master connect wrapper is robust. If a connection fails it will try to reconnect a few times and run that query again. All the slaves and masters are on the same switch so if one fails, generally speaking, they all fail.
What if one of the slaves loses its heartbeat with master one and falls over to master two when other slaves can still see master one. Don't you then have inconsistencies in your data?
The heartbeat code is pretty robust too. It's similar to the above wrapper and has the same benefits.
Having said all that, I did mention that this is an inexpensive medium sized solution to availability and that it is a read-heavy, write-light DB scenario. Additionally there is no data of a financial nature (if there was, we would be using another set-up - commit / rollback for example..). As such we are tolerant to very small amounts of data loss in the event of a failover situation.
On this, I refer you to the "how many 9's do you need" dscussion, nicely explained by Jeremy here:
http://jeremy.zawodny.com/blog/archives/000805.html
Cheers,
Andrew
-----Original Message-----
From: Russell Horn [mailto:[EMAIL PROTECTED] Sent: Monday 02 February 2004 16:21
To: [EMAIL PROTECTED]
Subject: RE: Advise on High Availability configuration
Andrew Braithwaite wrote:
Each slave keeps a heartbeat to the master and in the event of a failure, changes it's master to master2.
So how does this bit work? If one master falls over and slaves move to master two, how do you rebuild master one without downtime? Don't the slaves try and use Master 1 as soon as it's back online even though its data is out of sync?
What if one of the slaves loses its heartbeat with master one and falls over to master two when other slaves can still see master one. Don't you then have inconsistencies in your data?
Russell.
-- Dr. Frank Ullrich, DBA Netzwerkadministration Heise Zeitschriften Verlag GmbH & Co KG, Helstorfer Str. 7, D-30625 Hannover E-Mail: [EMAIL PROTECTED] Phone: +49 511 5352 587; FAX: +49 511 5352 538
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
