RBL, RBR, and temporary tables-opracowanie

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
more 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 mode even when
temporary tables have been created. However, while using the row-based format, the MySQL server
cannot determine the logging mode 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 allowed when using binlog_format=ROW [2047], as long as any
nontransactional tables affected by the statements are temporary tables (Bug #14272672).
... zobacz całą notatkę