Bug #56362 replicate-wild-do-table not playing nice with database-level statements
Submitted: 30 Aug 2010 11:39 Modified: 3 Sep 2010 9:19
Reporter: Geert Vanderkelen Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Replication Severity:S4 (Feature request)
Version:mysql-5.1 OS:Any
Assigned to: Luis Soares CPU Architecture:Any

[30 Aug 2010 11:39] Geert Vanderkelen
Description:
It is documented that --replicate-wild-do-table=foo%.bar% will not
replicate database-level statements. You would need 'foo%.%' to make it
work, but then you can't use any filtering anymore on tables.

Would it be possible to allow database-level statements like CREATE
DATABASE when the exact database name is given in the filter, or, like
in this case, when --replicate-do-db is already given?

How to repeat:
Start with an empty Master, and Slave, with the latter configured as
follows:

[mysqld]
replicate-do-db = hamspam
replicate-do-table=hamspam.ham
replicate-wild-do-table=hamspam.spam\_%

The idea is that there are an undefined number of hamspam.spam_XXXX tables.

If you now do on the master:
 mysql> CREATE DATABASE hamspam;

On the slave, database `hamspam` is not available (as documented).

Suggested fix:
With --replicate-wild-do-table=hamspam.spam\_% allow database-level statements for the given database named `hamspam`?

Workaround:
Do the database level statements manually. Since dropping, creating and altering databases is something you do every day, I see this as kind of a valid workaround.
[3 Sep 2010 9:19] Geert Vanderkelen
Duplicate of #46110.