(mysql.info.gz) InnoDB and MySQL Replication

Info Catalog

(mysql.info.gz) InnoDB foreign key constraints

(mysql.info.gz) Using InnoDB tables

(mysql.info.gz) Multiple tablespaces

 
 15.7.5 `InnoDB' and MySQL Replication
 -------------------------------------
 
 MySQL replication works for `InnoDB' tables as it does for `MyISAM'
 tables. It is also possible to use replication in a way where the table
 type on the slave is not the same as the original table type on the
 master.  For example, you can replicate modifications to an `InnoDB'
 table on the master to a `MyISAM' table on the slave.
 
 To set up a new slave for a master, you have to make a copy of the
 `InnoDB' tablespace and the log files, as well as the `.frm' files of
 the `InnoDB' tables, and move the copies to the slave.  For the proper
 procedure to do this, see  Moving.
 
 If you can shut down the master or an existing slave, you can take a
 cold backup of the `InnoDB' tablespace and log files and use that to
 set up a slave.  To make a new slave without taking down any server you
 can also use the non-free (commercial) `InnoDB Hot Backup' tool
 (http://www.innodb.com/order.html).
 
 There are minor limitations in `InnoDB' replication:
 
    * `LOAD TABLE FROM MASTER' does not work for `InnoDB' type tables.
      There are workarounds: 1) dump the table on the master and import
      the dump file into the slave, or 2) use `ALTER TABLE TBL_NAME
      TYPE=MyISAM' on the master before setting up replication with
      `LOAD TABLE TBL_NAME FROM MASTER', and then use `ALTER TABLE' to
      alter the master table back to the `InnoDB' type afterward.
 
    * Before MySQL 4.0.6, `SLAVE STOP' did not respect the boundary of a
      multiple-statement transaction.  An incomplete transaction would
      be rolled back, and the next `SLAVE START' would only execute the
      remaining part of the half transaction. That would cause
      replication to fail.
 
    * Before MySQL 4.0.6, a slave crash in the middle of a
      multiple-statement transaction would cause the same problem as
      `SLAVE STOP'.
 
    * Before MySQL 4.0.11, replication of the `SET FOREIGN_KEY_CHECKS=0'
      statement does not work properly.
 
 Most of these limitations can be eliminated by using more recent server
 versions for which the limitations do not apply.
 
 Transactions that fail on the master do not affect replication at all.
 MySQL replication is based on the binary log where MySQL writes SQL
 statements that modify data. A slave reads the binary log of the master
 and executes the same SQL statements. However, statements that occur
 within a transaction are not written to the binary log until the
 transaction commits, at which point all statements in the transaction
 are written at once.  If a statement fails, for example, because of a
 foreign key violation, or if a transaction is rolled back, no SQL
 statements are written to the binary log, and the transaction is not
 executed on the slave at all.
 

Info Catalog

(mysql.info.gz) InnoDB foreign key constraints

(mysql.info.gz) Using InnoDB tables

(mysql.info.gz) Multiple tablespaces