List:Replication« Previous MessageNext Message »
From:CM Date:May 14 2009 12:10pm
Subject:Re: advice on master-master replication failover support
View as plain text  
Marcus,
 

--- On Thu, 5/14/09, Marcus Bointon <marcus@stripped> wrote:


From: Marcus Bointon <marcus@stripped>
Subject: Re: advice on master-master replication failover support
To: "MySQL replication" <replication@stripped>
Cc: "Carl Marcinik" <cmonthenet@stripped>
Date: Thursday, May 14, 2009, 8:37 AM


Carl wrote:

>> 1) multiple app servers sharing the same
>> MySQL master-master backend


This is exactly the situation I'm using mmm in. I have a master-master pair (no slaves)
and 8 app servers.

On 13 May 2009, at 21:25, Rick James wrote:

> * "Automatic" is not possible.

Well, it's working with mmm for me.

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

mmm monitors by connecting to back-ends and running queries. This works, but we've had
some problems with false alarms when queries are held up by long-running (> 1 hour)
transactions, or if a server is iowait saturated.

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

I agree, this is not much use for DBs.

> * Port (3306) forwarding -- a significant possibility

This is effectively what mmm does - it accepts connections on a floating IP and forwards
to the appropriate back-end.

> * 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.

The monitoring needs to be pretty intimate with the back-ends if it's not going to give
false alarms - simple ping or connect tests are not enough; you need to select databases
and run queries.

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


Again, mmm does this - you can use a separate IP for each role, and have any number of
back-ends supporting each.

I can't comment on the redundant networking aspect as I've not tried that, but I would
expect that this to be dealt with separately at a lower level.

Marcus
--Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@stripped | http://www.synchromedia.co.uk/



--MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=1




      
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