In March’s “LAMP Post” column, we started to look at MySQL’s replication subsystem. We covered how replication works, as well as putting it to use by configuring the master and slave(s). This month, in this inaugural “MySQL” column, let’s spend some time looking at the lesser known aspects of MySQL replication, including filtering and log inspection.
In March’s “LAMP Post” column, we started to look at MySQL’s replication subsystem. We covered how replication works, as well as putting it to use by configuring the master and slave(s). This month, in this inaugural “MySQL” column, let’s spend some time looking at the lesser known aspects of MySQL replication, including filtering and log inspection.
Filtering on the Master
There are times when you’d rather not replicate all the data from a master to its slave(s). For instance, your master database server may contain test or pre-production databases and typically these databases, much like the /tmp directory on Linux, really don’t need to survive after a disaster. Rather than wasting the bandwidth and disk space to replicate them, you can tell MySQL to simply ignore them. You can accomplish this by adding one or more configuration directives to the my.cnf file on the master.
Let’s assume that you’re using the test database on your master, but don’t wish to log any changes to tables in test to the master’s binary log. Simple add a line like binlog-ignore -db=test to my.conf file. Of course, you’ll need to restart MySQL for the change to take effect. If you want to ignore multiple databases, either specify a list…
binlog-ignore-db=test,scratch
… or add one entry per database:
binlog-ignore-db=test binlog-ignore-db=scratch
If, on the other hand, you’d rather provide a list of databases to replicate and let MySQL ignore the rest,…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
