Question

I developed a custom mechanism for real-time mySQL databases synchronization which provides higher reliability (data integrity) over time compared to the built-in mySQL master/slave replication.

The synchronization mechanism operates in periodic cycles routinely triggered every 5 seconds, constituted of the following phases:

1. the master database is ordered to produce a dump file thru mysqldump
2. the dump file is transmitted to a remote server, owning the slave database. This transfer exploits rsync‘s delta algorithm and data compression
3. the remote server waits to receive an acknowledgment to proceed
4. the remote server imports the received dump file into the slave mySQL database
5. the remote server acknowledges the local server that the synchronization cycle has completed

To prevent any inconsistency between master and slave, the dump file drops the whole slave database calling mysqldump with --add-drop-database.

Since the slave imports the dump file without interrupting the mySQL daemon, I’m worried if during the time window after mySQL reads the drop database instruction from the dump file, and before mySQL completes the recreation of all the tables, a mySQL client trying to access the database for a table not yet recreated may fail his request.

May this happen, or during the recreation any eventual client trying to access the database is quietly paused apart until its request can be executed? And eventually, what solutions can be applied?

Answer 1

To avoid pulling the rug out from under any clients that might be trying to connect to a particular database, the best approach might be to not DROP and CREATE the database with each refresh.

A method that might prove more reliable is to load in data into alternate tables one at a time, then do a mass switch. For instance:

CREATE TABLE __users (...);
INSERT INTO __users (...) VALUES (...), ...;

CREATE TABLE __things (...);
INSERT INTO __things (...) VALUES (...), ...;

RENAME users to _users, __users to users, things to _things, __things to things;
DROP table _users;
DROP table _things;

The mass rename operation would be executed atomically if you get everything lined up correctly.

You’ll either have to alter the names within the raw SQL dump itself, or dump into a format that’s more easily parsed, such as SELECT INTO ... OUTFILE and later restoring with LOAD DATA INFILE.

Note that this approach will not handle VIEW or TRIGGER objects, among other things. It will only work with plain old tables. You’ll also need to have enough free space to create two copies of your entire database during the reload procedure.