Bug#11829838: ALTER TABLE NOT BINLOGGED WITH
--BINLOG-IGNORE-DB AND FULLY QUALIFIED TABLE Problem: ======= An ALTER TABLE statement is not written to binlog if server started with "--binlog-ignore-db some database" and 'fully qualified' table names are used in the ALTER TABLE statement altering table different from current database context. Analysis: ======== The above mentioned problem not only affects "ALTER TABLE" statements but also to all kind of statements. Once the current default database becomes "NULL" none of the statements will be binlogged. The current behaviour is such that if the user has specified restrictions on which database needs to be replicated and the default db is not specified, then do not replicate. This means that "NULL" is considered to be equivalent to everything (default db = null implied ignore don't log the statement). Fix: === "NULL" should not be considered as equivalent to everything. Since the filtering criteria is not equal to "NULL" the statement should be logged into binlog. mysql-test/suite/rpl/r/rpl_loaddata_m.result: Earlier when defalut database was "NULL" DROP TABLE was not getting logged. Post this fix it will be logged and the DROP will fail at slave as the table creation was skipped by master as --binlog-ignore-db=test. mysql-test/suite/rpl/t/rpl_loaddata_m.test: Earlier when defalut database was "NULL" DROP TABLE was not getting logged. Post this fix it will be logged and the DROP will fail at slave as the table creation was skipped by master as --binlog-ignore-db=test. sql/rpl_filter.cc: Replaced DBUG_RETURN(0) with DBUG_RETURN(1).
Showing
Please register or sign in to comment