Master/Slave without populating tables So I have some Zabbix instances which are using MySQL for their backends. What I would like to do is, for DR purposes, backup the DBs for each instance using a Master/Slave configuration, with the slave node sitting at the DR site. However, I don't want to capture trends/historical data, all I want is configuration data. Is there a way to replicate Zabbix's database without populating the tables which hold all of the applications historical monitoring metrics?
@RolandoMySQLDBA's answer is accurate, but I would advise against using the replicate-*-table and replicate-*-db options because of the complexity of how MySQL evaluates replication rules.

When these aren't used, everything is replicated, and I would contend that replicating everything the most reliable configuration.  As a rule, I never do anything else.

If you don't want to replicate the historical data, I would start by setting up a full, standard master/slave replication setup...

...then... 

...identify the tables you don't care about on the replica and for each such table, on the slave:

ALTER TABLE table_name ENGINE=BLACKHOLE;


This will discard all of the data in those tables on the slave and convert them to the blackhole storage engine, which accepts inserts (but doesn't store them), returns empty result-sets from selects, and has "0 rows affected" on updates and deletes... so your schemata are still fully compatible but you're not actually storing anything in the tables you're not interested in.

If you're using mysqldump to initially set up the replica, you can also manually edit the dump files and change the table engine on those tables' declarations.

All of the data will still be "replicated to" the slave, but not "saved on" the slave... the data written to these tables will not be stored.  Writing rows to a blackhole table is a very resource-friendly operation -- I've seen my servers handle 40,000+ queries per second when replicating "into" blackhole tables.

If you're concerned about the fact that the data is still transferred to the replica... or, really, even if you're not, just turn on slave_compressed_protocol on the slave and don't think about it -- consider it the cost of a cleaner replication setup.  When the slave connects to the master, it will negotiate a connection using the MySQL compressed client protocol, substantially reducing the actual bytes of data transferred on the wire between the machines, but still sending everything.