1
0
mirror of https://github.com/MariaDB/server.git synced 2025-09-02 09:41:40 +03:00
Commit Graph

4 Commits

Author SHA1 Message Date
unknown
2b2ce3d6cb Bug #49137 Replication failure on SBR/MBR + multi-table DROP TEMPORARY TABLE
In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE
to drop multiple tables causes different errors on master and slave, 
when one or more of these tables do not exist. Because when executed
on slave, it would automatically add IF EXISTS to the query to ignore
all ER_BAD_TABLE_ERROR errors.

To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY
TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after
execution if the query does not expect any errors.


mysql-test/r/rpl_drop_temp.result:
  Updated for the patch of bug#49137.
mysql-test/t/rpl_drop_temp.test:
  Added the test file to verify if DROP MULTI TEMPORARY TABLE
  will cause different errors on master and slave, when one or
  more of these tables do not exist.
sql/log_event.cc:
  Added code to handle above cases which are
  removed from sql_parse.cc
sql/sql_parse.cc:
  Remove the code to issue the 'Unknown table' error,
  if the temporary table does not exist when dropping
  it on slave. The above cases decribed in comments
  will be handled later in log_event.cc.
2009-12-31 11:33:10 +08:00
Alfranio Correia
ea06bbd2b0 BUG#46861 Auto-closing of temporary tables broken by replicate-rewrite-db
When a connection is dropped any remaining temporary table is also automatically
dropped and the SQL statement of this operation is written to the binary log in
order to drop such tables on the slave and keep the slave in sync. Specifically,
the current code base creates the following type of statement:
DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;

Unfortunately, appending the database to the table name in this manner circumvents
the replicate-rewrite-db option (and any options that check the current database).
To solve the issue, we started writing the statement to the binary as follows:
use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
2009-08-27 17:28:09 +01:00
unknown
e28dc4c7ef log_event.cc:
#ifdef USING_TRANSACTIONS
ha_innodb.cc:
  comment
rpl_drop_temp.test, rpl_drop_temp.result:
  cleanup


mysql-test/r/rpl_drop_temp.result:
  cleanup
mysql-test/t/rpl_drop_temp.test:
  cleanup
sql/ha_innodb.cc:
  comment
sql/log_event.cc:
  #ifdef USING_TRANSACTIONS
2005-03-16 23:47:38 +01:00
unknown
4cead8c8a5 1) undoing my fix for BUG#8055 "Trouble with replication from temporary tables and ignores"
and fixing it another way (per Monty; a simpler solution which does not increase the number
of binlog events is to always execute DROP TEMPORARY TABLE IF EXISTS on slave). A new test rpl_drop_temp.
2) fixing BUG#8436 "Multiple "stacked" SQL statements cause replication to stop" by setting
thd->query_length to the length of the query being executed, not counting the next queries
if this is a multi-query. Should also improve display of SHOW PROCESSLIST. A new test rpl_multi_query.



mysql-test/r/drop_temp_table.result:
  back to one single DROP
sql/sql_base.cc:
  undoing the fix I had made some days ago: we are back to one single DROP TEMPORARY TABLE for all temp tables.
sql/sql_parse.cc:
  1) set thd->query_length to the length of the query being executed, excluding the other next queries
  if this is a multi-query. The setting happens ASAP, ie. just after we know it's a multi-query, ie. just after yyparse().
  Don't include the ';' in thd->query_length, because this is not good for storage in binlog.
  2) always execute a DROP TEMPORARY TABLE IF EXISTS on slave, don't skip it even if --replicate-ignore-table
2005-02-14 23:47:17 +01:00