mirror of
https://github.com/MariaDB/server.git
synced 2025-01-30 10:31:54 +01:00
f94e7288e3
FAILED DROP DATABASE CAN BREAK STATEMENT BASED REPLICATION The first phase of DROP DATABASE is to delete the tables in the database. If deletion of one or more of the tables fail (e.g. due to a FOREIGN KEY constraint), DROP DATABASE will be aborted. However, some tables could still have been deleted. The problem was that nothing would be written to the binary log in this case, so any slaves would not delete these tables. Therefore the master and the slaves would get out of sync. This patch fixes the problem by making sure that DROP TABLE is written to the binary log for the tables that were in fact deleted by the failed DROP DATABASE statement. Test case added to binlog.binlog_database.test. |
||
|---|---|---|
| .. | ||
| binlog.test | ||
| binlog_cache_stat.test | ||
| binlog_insert_delayed.test | ||
| binlog_truncate.test | ||
| blackhole.test | ||
| ctype_cp932.test | ||
| ctype_cp932_binlog.test | ||
| ctype_ucs_binlog.test | ||
| database.test | ||
| drop_table.test | ||
| drop_temp_table.test | ||
| implicit.test | ||
| insert_select-binlog.test | ||
| mix_innodb_myisam_binlog.test | ||
| mix_innodb_myisam_side_effects.test | ||