MySQL Replicate Databases without Tables or Content

Posted on

Question :

I would like to replicate all the databases from a MySQL master to a slave used for archiving data older than 30 days. It isn’t common for this data to be accessed so I would like it removed from the master. I only need to replicate the database table structure without any content. But only two tables (tablea and tableb) out of the 10 tables need to be created in the database structure.

The table content will be imported using an archive script that is using pt-archiver which is why I don’t need the content replicated to the slave. However when the main database is removed from the master it should also remove the database from this archive slave. Is this possible using replication?

Answer :

It isn’t possible with replication as has been correctly pointed out, since that’s not how replication works, nor can it be configured to work that way. Replication either does or does not handle any given table (depending on configuration) but when replication does handle a given table, the data is replicated and replication depends on the rows in the tables starting out and remaining identical.

What I’m hearing you say is that you want some of the same schemas and tables on the 2nd server as exist on the master, but they will be populated via external means, and you want those tables to go away when they are dropped from the master.

Here is a high-level view of how this could be accomplished via automatic means using only things built-in to MySQL.

Obviously this is a dangerous operation if not carefully written since we’re talking about the automated dropping of tables and databases, so… caveat lector.

  • enable the event scheduler on the archive machine
  • enable the federated storage engine on the archive machine
  • within another schema you create solely for the purpose of this exercise, define 2 FEDERATED tables that connect back to the master. One of these points to information_schema.tables and the other points to information_schema.schemata.
  • write a stored procedure that selects from the archive machine’s information_schema.schemata table, left join the federated schemata table on catalog_name, schema_name where schema_name not in (‘mysql’,’information_schema’,’performance_schema’,’any’,’other’,’schemas’,’you want not’,’to be deleted’,’for sure’)
  • take values from the resulting rows, which will be all of the databases that exist on the local machine but not on the master… and, using dynamic sql, drop those databases from the archive machine.
  • do the same thing with the information_schema.tables table, which will identify tables you can drop.
  • use the event scheduler to automate the running of this stored procedure. Don’t schedule it too often, perhaps only once a day, because selecting from the information_schema.tables table can be a resource-intensive operation. MySQL gathers stats when you do this that can be costly especially in terms of I/O.

How Replication works in MySQL:

Replication between servers in MySQL is based on the binary logging mechanism. The MySQL instance operating as the master (the source of the database changes) writes updates and changes as “events” to the binary log. The information in the binary log is stored in different logging formats according to the database changes being recorded. Slaves are configured to read the binary log from the master and to execute the events in the binary log on the slave’s local database.

This means using replication you can’t only copy structure of tables to slave it will replicate data also from master.


You should enable this option for tableA and tableB so that only these tables will get replicate others will be skipped.

Leave a Reply

Your email address will not be published. Required fields are marked *