Tungsten replicator does not correctly handle temporary tables when MySQL statement replication is enabled. For instance, if you use a temporary table to populate another table, the CREATE TEMPORARY TABLE command must be replicated to the slave. This results in failures due to the following:
1.) Multiple master sessions may simultaneously use temp tables, resulting in DDL errors on the slave side as the single applier thread tries to create multiple tables simultaneously.
2.) Autocommit transactions may be interleaved in such a way that statements succeed but the results use data from the wrong "version" of a temp table.
The root cause of this problem is the same as TREP-70. We need to track session data and segregate users of the same temp table.
NOTE: MySQL handling of temp tables is highly problematic and does not handle failure situations. The correct long-term workaround/solution is for applications to use 5.1 with row-based replication. However, not all users can upgrade, so this problme needs to be solved.
This problem is resolved by enabling com.continuent.tungsten.replicator.filter.MySQLSessionSupportFilter to add session IDs to events. The filter prevents temp table conflicts on the slave.
Bug
Resolved
Blocker
Tungsten replicator does not replicate temporary tables correctly in MySQL statement replication
