Skip navigation links

MySQL Forums :: Replication :: Three Node Replication (US West, US East and Europe)


Advanced Search

Re: Three Node Replication (US West, US East and Europe)
Posted by: Tom Anders ()
Date: March 22, 2012 11:22PM

Hi Rick! Thanks kindly for the reply. Your advice correlates to what I was reading on the net; that is, avoid N > 2 Master-Master replication due to the potential problems you indicated.

Hence, we were going to avoid Master-Master across the pond for now and simply get a much larger server on the US East Coast and start from there, reducing complexity and failure points, I think. We were going to go the GeoDNS route to direct traffic from various regions to the "local" server(s); but that also seems to add a degree of complexity that can be avoided by simply getting a better/faster configuration at a single data center on the US East Coast in New Jersey (or closer to the center of the US, like St. Louis or Dallas).

You mentioned "write to the master" - "read from the slaves"; I've not configured that before. That sounds promising, thanks.

Do you have a reference on how to set this up? I assume the set up for this is at the my.cnf configuration level for each master and slave and the application does not need to be redesigned? Is that right?

Thank you again for taking the time to advise.

Options: ReplyQuote


Subject Views Written By Posted
Three Node Replication (US West, US East and Europe) 1665 Tom Anders 03/22/2012 01:44AM
Re: Three Node Replication (US West, US East and Europe) 602 Rick James 03/22/2012 09:02PM
Re: Three Node Replication (US West, US East and Europe) 563 Tom Anders 03/22/2012 11:22PM
Re: Three Node Replication (US West, US East and Europe) 544 Rick James 03/23/2012 07:55PM
Re: Three Node Replication (US West, US East and Europe) 581 Tom Anders 03/25/2012 12:59AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.