List:Replication« Previous MessageNext Message »
From:Rick James Date:May 13 2009 8:25pm
Subject:RE: advice on master-master replication failover support
View as plain text  
* "Automatic" is not possible.

* Need to monitor for failure, then be able to double check that it is not a false alarm.

* DNS for redirecting traffic --> can take many minutes (TTL + caching)

* Port (3306) forwarding -- a significant possibility

* Software or hardware load balancing, such that the passive master appears to be "not
available" -- a significant possibility.  Change the health check after establishing it
as the read-write master.

* Different port or different logical host name -- helpful in segregating readonly
connects versus read-write connects.

No, I can't juge which is the best starting point.

 
Rick James
MySQL Geeks - Consulting & Review

 

> -----Original Message-----
> From: Carl Marcinik [mailto:cmonthenet@stripped] 
> Sent: Wednesday, May 13, 2009 12:39 PM
> To: replication@stripped
> Subject: advice on master-master replication failover support
> 
> Hi,
>     We've been using MySQL for a few years but have only done 
> master-slave replication. For several reasons, for an 
> upcoming project we want to use master-master replication in 
> active/passive mode (active master can read/write, "passive" 
> can only read). We need automatic failover support, but it 
> has to work  for 1) multiple app servers sharing the same 
> MySQL master-master backend and 2) redundant networks between 
> the app servers and the DB servers (all servers have two 
> network ports connected to different subnets). 
> 
> I have been looking at MMM Replication Manager and Heartbeat, 
> but neither seem to have all that I need. The question is: Is 
> either one of these a better starting point for what I want 
> to do? Is there a better way (taking into consideration, I 
> need to fail over the write role when the active master fails)?
> 
> I would appreciate any sage advice!
> 
> Thanks,
> CM 
> 
> 
>       
> 
Thread
advice on master-master replication failover supportCarl Marcinik13 May
  • RE: advice on master-master replication failover supportRick James13 May
    • Re: advice on master-master replication failover supportMarcus Bointon14 May
      • RE: advice on master-master replication failover supportRick James15 May
Re: advice on master-master replication failover supportCM14 May
Re: advice on master-master replication failover supportCM14 May
Re: advice on master-master replication failover supportCM14 May
Re: advice on master-master replication failover supportCM14 May
Re: advice on master-master replication failover supportCM14 May
Re: advice on master-master replication failover supportCM14 May