Two-way MySQL replication?
There are two web servers: server1 and server2. Server1 is the primary and server2 is the backup / redundant box.
We have failover DNS setup through DNSMadeEasy so that if there is an issue with Server1, the DNS will re-point to server2 until server1 can come back online.
Both of these servers run a single php / mysql based website.
Here's the question: if we setup MySQL replication, will that accomplish the following:
1. If server1 goes down, server2 will show up with all the content. (Content is in the database).
2. If users make changes or upload things to server2, when server1 comes back up, will the changes replicate back to server1?
Right now, the though is to use MySQL replication to replicate the data, and rsync to sync the files.
I know this can be done. the question is, what are the specifics? And, how long would it take a competent MySQL admin to set this up?
We have failover DNS setup through DNSMadeEasy so that if there is an issue with Server1, the DNS will re-point to server2 until server1 can come back online.
Both of these servers run a single php / mysql based website.
Here's the question: if we setup MySQL replication, will that accomplish the following:
1. If server1 goes down, server2 will show up with all the content. (Content is in the database).
2. If users make changes or upload things to server2, when server1 comes back up, will the changes replicate back to server1?
Right now, the though is to use MySQL replication to replicate the data, and rsync to sync the files.
I know this can be done. the question is, what are the specifics? And, how long would it take a competent MySQL admin to set this up?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Last time I set it up was about 3 years ago, so I can't remember the exact time, but I remember that when everything went perfectly, it took like 15 minutes. Usually there's always some problem, so I would count on a couple hours of troubleshooting and learning time when one step doesn't produce the intended result. It's one of those precise operations, so sometimes it takes more than one try to get it right.
ASKER
Regarding primary key collisions: it should not make a difference for existing data (because the databases already have thousands of records. We should be able to setup the offsets for "new" records and avoid any sort of issue.
...that is, of course, unless someone modifies an old record with an existing ID. What happens then?
...that is, of course, unless someone modifies an old record with an existing ID. What happens then?
That's correct. The offsets only impact NEW primary key IDs. It doesn't matter if you update an existing record on either server. The idea behind the replication is that ALL changes are copied to the other server, and both are simultaneously active (so you can make changes to either one at any time). If the one server is unavailable, the other server simply remembers the last point in time in the query log (binary log) where successful replication happened. So when server B comes back up, server A is able to send all of the activity that happened while B was down.
That said, it is sometimes a good idea to introduce an INTENTIONAL delay in replication (if it's not in that guide, just google around - there's a way to do it). This way, if you have someone accidentally drop a table or delete data that brings down Server A, you don't replicate the deletion right away to B, and you can have that short window of time (e.g. 30 minutes or an hour) to save your butt.
For my purposes, I didn't introduce a delay but simply had my server B perform hourly, incremental backups of itself with a full daily dump.
That said, it is sometimes a good idea to introduce an INTENTIONAL delay in replication (if it's not in that guide, just google around - there's a way to do it). This way, if you have someone accidentally drop a table or delete data that brings down Server A, you don't replicate the deletion right away to B, and you can have that short window of time (e.g. 30 minutes or an hour) to save your butt.
For my purposes, I didn't introduce a delay but simply had my server B perform hourly, incremental backups of itself with a full daily dump.
ASKER
gr8gonzo... not sure if you saw this, but insight is invited:
https://www.experts-exchange.com/questions/28393565/Two-way-MySQL-replication-not-working.html
https://www.experts-exchange.com/questions/28393565/Two-way-MySQL-replication-not-working.html
ASKER
I am really only worried about the setup time. Replication time is dependent on network speeds available, etc... which I have little control over. The server receives relatively low traffic, but is mission critical to a client's business. So, it can't go down because "when we need it, we need it."