MySQL applies these rules when
TABLE ... SELECT statements are replicated:
CREATE TABLE ... SELECTalways performs an implicit commit (Section 13.3.3, “Statements That Cause an Implicit Commit”).
If the destination table does not exist, logging occurs as follows. It does not matter whether
IF NOT EXISTSis present.
MIXEDformat: The statement is logged as written.
ROWformat: The statement is logged as a
CREATE TABLEstatement followed by a series of insert-row events.
If the statement fails, nothing is logged. This includes the case that the destination table exists and
IF NOT EXISTSis not given.
If the destination table exists and
IF NOT EXISTSis given, MySQL ignores the statement completely; nothing is inserted or logged.
MySQL 5.6 does not allow a
TABLE ... SELECT statement to make any changes in
tables other than the table that is created by the statement.
This is a change in behavior from previous versions of MySQL,
which permitted these statements to do so. This means that, when
using statement-based replication between a MySQL 5.6 or later
slave and a master running a previous version of MySQL, a
TABLE ... SELECT statement causing changes in other
tables on the master fails on the slave, causing replication to
stop. To keep this from happening, you should use row-based
replication, rewrite the offending statement before running it
on the master, or upgrade the master to MySQL 5.6 (or later).
(If you choose to upgrade the master, keep in mind that such a
TABLE ... SELECT statement will fail following the
upgrade unless it is rewritten to remove any side effects on
other tables.) This is not an issue when using row-based
replication, because the statement is logged as a
CREATE TABLE statement with any
changes to table data logged as row-insert events, rather than
as the entire
TABLE ... SELECT.