Bug #269 Replication fails on interrupted temporary table processes

• Submitted: 10 Apr 2003 8:51
• Modified: 10 Apr 2003 14:27
• Reporter: [ name withheld ]
• Status: Closed
• Category: MySQL Server: Replication
• Severity: S3 (Non-critical)
• Version: 3.23.52
• OS: Linux (Linux/Suse)
• CPU Architecture: Any

[10 Apr 2003 8:51] [ name withheld ]

Description:
Replication fails, the master sends a command in the binary log to drop temporary tables, which never existed on the replication hosts. It appears (to a novice), that whatever function reaps temporary tables from killed processes drops the tables without flagging the command not to be replicated.

How to repeat:
Create a temporary table from a select on the master, using a long-running query. On another connection to the master, find the connection creating that temporary table, and kill it. Within a minute or so, you will get a DROP TABLE command sent to the slave, for a table the slave never knew about, and the slave will fail.

Suggested fix:
Commands related to temporary tables should never be replicated.

[10 Apr 2003 14:27] Guilhem Bichot

Thank you for your bug report. This issue has been fixed in the latest
development tree for that product. You can find more information about
accessing our development trees at 
    http://www.mysql.com/doc/en/Installing_source_tree.html

Hi,

Thanks for your bug report. This is known and is fixed in
MySQL 4.0.13 (not released yet). Since 4.0.5, the automatic
DROP TABLE is instead DROP TEMPORARY TABLE. Since 4.0.13,
the slave silently translates
DROP TEMPORARY TABLE
to
DROP TEMPORARY TABLE IF EXISTS
so you don't get a "table doesn't exist" error anymore.

[6 Jan 2005 22:45] Ted Cui

This bug comes back at least for 4.0.18.