The world's most popular open source database
This section discusses the rules that are applied when a
CREATE TABLE ... SELECT statement is
replicated.
CREATE TABLE ... SELECT always performs an
implicit commit (Section 12.4.3, “Statements That Cause an Implicit Commit”).
Statement succeeds.
If the CREATE TABLE ... SELECT statement
succeeds on the master, then it is replicated as follows:
STATEMENT or MIXED format.
The CREATE TABLE ... SELECT
statement is itself replicated.
ROW format.
The statement is replicated as a
CREATE TABLE statement
followed by a series of binwrite
events (that is, binary inserts).
Statement fails.
The failure of a CREATE TABLE ... SELECT is
handled according to the following criteria:
No IF NOT EXISTS option.
If the CREATE TABLE ... SELECT does
not contain an IF NOT EXISTS
option, then the statement has no effect. However, the
implicit commit caused by the statement is logged.
This is true regardless of the replication format,
storage engine used, and the reason for which the
statement failed.
Statement uses IF NOT EXISTS.
If the CREATE TABLE ... SELECT
statement includes the IF NOT
EXISTS option and fails, the failure is
handled according to the replication format. If the
row-based format is in use, the action taken depends
additionally on whether or not the table to be created
uses a transactional or non-transactional storage
engine, and on the reason for the failure:
STATEMENT or MIXED format.
When using statement-based or mixed-format
replication, the CREATE TABLE IF NOT
EXISTS ... SELECT is logged with an
error.
ROW format.
When row-based replication is used, failure of
a CREATE TABLE ... SELECT
that includes IF NOT EXISTS
is handled differently depending on the reason
for the failure, as shown in the following
diagram:



User Comments
Add your own comment.