89450

RBL, RBR, and temporary tables. As noted in Section 16.4.1.22, “Replication and Temporary

Tables”, temporary tables are not replicated when using row-based format. When mixed format is in

effect, "safe" statements involving temporary tables are logged using statement-based format. For

morę information, see Section 16.1.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.

Temporary tables are not replicated when using row-based format because there is no need. In

addition, because temporary tables can be read only from the thread which created them, there is

seldom if ever any benefit obtained from replicating them, even when using statement-based format.

In MySQL 5.6, you can switch from statement-based to row-based binary logging modę even when

temporary tables have been created. However, while using the row-based format, the MySQL server

cannot determine the logging modę that was in effect when a given temporary table was created.

For this reason, the server in such cases logs a DROP TEMPORARY TABLE IF EXISTS statement

for each temporary table that still exists for a given Client session when that session ends. While this

means that it is possible that an unnecessary DROP TEMPORARY TABLE statement might be logged

in some cases, the statement is harmless, and does not cause an error even if the table does not

exist, due to the presence of the IF NOT EXISTS option.

In MySQL 5.6.6 and earlier, the —disable-gtid-unsafe-statements [2056] option caused

any nontransactional DML statement involving temporary tables to fail with an error when using

row-based logging, in spite of the fact that they are not written to the binary log. In MySQL 5.6.7

and later, such statements are allowsd when using binlog_format=ROW [2047], as long as any

nontransactional tables affected by the statements are temporary tables (Bug #14272672).