This section discusses how MySQL replicates
CREATE
TABLE ... SELECT statements.
These behaviors are not dependent on MySQL version:
CREATE
TABLE ... SELECT always performs an implicit
commit (Section 13.3.3, “Statements That Cause an Implicit Commit”).
If destination table does not exist, logging occurs as
follows. It does not matter whether IF NOT
EXISTS is present.
STATEMENT or MIXED
format: The statement is logged as written.
ROW format: The statement is logged
as a CREATE TABLE
statement 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
EXISTS is not given.
When the destination table exists and IF NOT
EXISTS is given, MySQL handles the statement in a
version-dependent way.
In MySQL 5.1 before 5.1.51 and in MySQL 5.5 before 5.5.6 (this is the original behavior):
STATEMENT or MIXED
format: The statement is logged as written.
ROW format: The statement is logged as a
CREATE TABLE statement
followed by a series of insert-row events.
In MySQL 5.1 as of 5.1.51:
STATEMENT or MIXED
format: The statement is logged as the equivalent pair of
CREATE TABLE and
INSERT INTO
... SELECT statements.
ROW format: The statement is logged as a
CREATE TABLE statement
followed by a series of insert-row events.
In MySQL 5.5 as of 5.5.6:
Nothing is inserted or logged.
These version dependencies arise due to a change in MySQL 5.5.6
in handling of
CREATE
TABLE ... SELECT not to insert rows if the destination
table already exists, and a change made in MySQL 5.1.51 to
preserve forward compatibility in replication of such statements
from a 5.1 master to a 5.5 slave. For details, see
Section 13.1.17.4, “CREATE TABLE ... SELECT Syntax”.
When using statement-based replication between a MySQL 5.6 or
later slave and a master running a previous version of MySQL, a
CREATE
TABLE ... SELECT statement causing changes in other
tables on the master fails on the slave, causing replication to
stop. This is due to the fact that MySQL 5.6 does not allow a
CREATE
TABLE ... SELECT statement to make any changes in
tables other than the table that is created by the
statement—a change in behavior from previous versions of
MySQL, which permitted these statements to do so. 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
CREATE
TABLE ... SELECT statement will fail there as well,
following the upgrade, unless the statement 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 (or possibly row-update events), rather than as the
entire
CREATE
TABLE ... SELECT statement.