Skip navigation links
MySQL 5.1 Reference Manual :: 16 Replication :: 16.4 Replication Notes and Tips :: 16.4.1 Replication Features and Issues :: 16.4.1.4 Replication of CREATE TABLE ... SELECT Statements
16.4.1.5 Replication with Differing Table Definitions on Master and Slave »
Section Navigation      [Toggle]

16.4.1.4. Replication of CREATE TABLE ... SELECT Statements

This section discusses the rules that are applied when a CREATE TABLE ... SELECT statement is replicated.

Note

CREATE TABLE ... SELECT always performs an implicit commit (Section 12.3.3, “Statements That Cause an Implicit Commit”).

Statement succeeds.  A successful CREATE TABLE ... SELECT replicates 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.  A failed CREATE TABLE ... SELECT replicates as follows:

  • Statement does not use IF NOT EXISTS.  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.  The failure is handled according to the replication format. If the row-based format is in use, the action taken depends additionally on whether the table to be created uses a transactional or nontransactional storage engine, and on the reason for the failure:

    • STATEMENT or MIXED format.  The CREATE TABLE IF NOT EXISTS ... SELECT is logged with an error.

    • ROW format.  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 table.

      CREATE TABLE IF NOT EXISTS ... SELECT Failure Handling (RBR)