MySQL offers a few different options for how you perform replication. Statement-based has been around a lot longer, and though it has some troublesome characteristics they’re known well and can be managed. What’s more it supports online schema changes with multi-master active-passive setup. We recommend this solution.
Row-based replication is newer. It attempts to address problems like those introduced by non-deterministic functions, and replicating stored procedures. But it introduces it’s own challenges.
Click through to the end for multi-master solutions that work with MySQL.
3. Row-based replication limitations
Row-based replication addresses some of the limitations of statement based replication.
o works better with stored procedures
o reduces problems associated with non-deterministic functions
But it creates a few of it’s own, some are show-stoppers:
o won’t work if target table storage engine, column order, data types or row itself are different or missing.
o doesn’t write SQL to the binlogs – useful for troubleshooting
o harder to do point-in-time recovery without SQL in binlogs
o harder to do online schema changes by switching masters
NEXT: Reason 4 – Cannot reclone without a single master
PREV: Reason 2 – MySQL Replication is prone to failure
Database replication is a service for shipping changes to your database, off to a copy housed on another server, potentially even in another data center.
Each change to the records of information in your database or groups of them are organized into transactions. These each get unique identifiers or change numbers. Those groupings of changes are logged to transaction logs which are then moved across to the sibling database server, and applied there.
Oracle offers this facility in the form of Standby Database aka Dataguard. Although it can be messy to setup, it is fairly bulletproof. If you don’t receive any errors in your logfiles, you can rest assured that the data on your main or master database server looks exactly the same as what’s on your secondary server. With MySQL the situation can be a bit more complicated. MySQL replication was built based on statements, not changed data. So those same statements or instructions (SQL statements of DML & DDL) get rerun on the secondary database server. Some of the problems associated with this are:
- MySQL standby transactions may execute at different times than master
- Serialization is important to maintain order. Transactions need to get applied in the same order as on the primary. However all tables & storage engines are not necessarily transactional in MySQL. This can cause troubles, and potentially break replication on the slave side.
- MySQL replication can fail silently, that is data can drift out of sync with the master without your knowing.
Caveats aside, MySQL replication is powerful, and quite fast. With the right caution, and correct tools, it can be as robust and reliable as Oracle’s own standby database technology.
- Use checksum tools like Maatkit to verify & compare tables on primary & secondary servers
- Use rigorous monitoring to watch error logs, and checksum logs hourly if necessary.
- Use Maatkit sync tool to resync tables if they get out of whack.
- Be especially vigilant if you’re taking backups off the secondary server
Replication can also be a powerful high availability tool in your arsenal. Setup as a master-master cluster, you can keep your application pointed to the “active” side or role while performing blocking operations on the inactive database server. Since master-master cluster also known as circular replication applies changes to both databases, you’ll need to stop replication during the blocking operation. Once it is completed on the inactive side, redirect the webservers & application to the database where you completed the operation, then reenable replication and watch the databases catch up with each other!
Quora discussions – What is database replication?