19.1 Database replication

The most general way to replicate a database is to use the update log. 9.2 The update log. This requires one database that acts as a master (to which data changes are made) and one or more other databases that act as slaves. To update a slave, just run mysql < update_log. Supply host, user and password options that are appropriate for the slave database, and use the update log from the master database as input.

If you never delete anything from a table, you can use a TIMESTAMP column to find out which rows have been inserted or changed in the table since the last replication (by comparing to the time when you did the replication last time) and only copy these rows to the mirror.

It is possible to make a two-way updating system using both the update log (for deletes) and timestamps (on both sides). But in that case you must be able to handle conflicts when the same data have been changed in both ends. You probably want to keep the old version to help with deciding what has been updated.

Because replication in this case is done with SQL statements, you should not use the following functions in statements that update the database; they may not return the same value as in the original database:

• DATABASE()
• GET_LOCK() and RELEASE_LOCK()
• RAND()
• USER(), SYSTEM_USER() or SESSION_USER()
• VERSION()

All time functions are safe to use, as the timestamp is sent to the mirror if needed. LAST_INSERT_ID() is also safe to use.