> >> >> I have already a setup that includes one master and several slaves that >> are load balanced using Keepalived (http://www.keepalived.org). This has >> served me very well for a year. >> >> What I want now is to have a second master that would take over if the >> primary master goes down, i.e. reduce the time it would take to have a >> new >> master fully operational. >> >> Thanks for your input on DRBD anyway. > > A slave that is using the same database as the master should be > reconfigurable via a very small shell script to become a master in a > matter > of seconds. >
Quanah, This part is the one I was the least concerned about. My two problems are: 1) After a failover to the secondary master, what should we do with the primary? What if the primary comes back online? The simplest solution is provided by that article pointed out by Gary: prevent the failed node to re-acquire the virtual IP. 2) I would like to use syncrepl as the synchronization mechanism between my master and slaves. Let's assume my primary master fails and one the slaves takes over after being reconfigured as a master. Will synchronization work between the new master and the other slaves? I am not sure about that because of what I read in the admin doc: "Syncrepl keeps track of the status of the replication content by maintaining and exchanging synchronization cookies. Because the syncrepl consumer and provider maintain their content status, the consumer can poll the provider content to perform incremental synchronization by asking for the entries required to make the consumer replica up-to-date with the provider content. Syncrepl also enables convenient management of replicas by maintaining replica status. The consumer replica can be constructed from a consumer-side or a provider-side backup at any synchronization status. Syncrepl can automatically resynchronize the consumer replica up-to-date with the current provider content." Thanks. Sam
