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 nontransactional
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.