If, during recovery, InnoDB  encounters redo logs written since the last checkpoint, the redo logs must be applied to affected tablespaces. The process that identifies affected tablespaces during recovery is referred to as tablespace discovery . 

Tablespace discovery relies on the innodb_directories  setting, which defines the directories to scan at startup for tablespace files. The innodb_directories  default setting is NULL, but the directories defined by innodb_data_home_dir , innodb_undo_directory , and datadir  are always appended to the innodb_directories  argument value when InnoDb builds a list of directories to scan at startup. These directories are appended regardless of whether an innodb_directories  setting is specified explicitly. Tablespace files defined with an absolute path or that reside outside of the directories appended to the innodb_directories  setting should be added to the innodb_directories  setting. Recovery is terminated if any tablespace file referenced in a redo log has not been discovered previously. 

## 15.19 InnoDB and MySQL Replication 

It is possible to use replication in a way where the storage engine on the replica is not the same as the storage engine on the source. For example, you can replicate modifications to an InnoDB  table on the source to a MyISAM  table on the replica. For more information see, Section 17.4.4, “Using Replication with Different Source and Replica Storage Engines” . 

For information about setting up a replica, see Section 17.1.2.6, “Setting Up Replicas” , and Section 17.1.2.5, “Choosing a Method for Data Snapshots” . To make a new replica without taking down the source or an existing replica, use the MySQL Enterprise Backup product. 

Transactions that fail on the source do not affect replication. MySQL replication is based on the binary log where MySQL writes SQL statements that modify data. A transaction that fails (for example, because of a foreign key violation, or because it is rolled back) is not written to the binary log, so it is not sent to replicas. See Section 13.3.1, “START TRANSACTION, COMMIT, and ROLLBACK Statements” . 

Replication and CASCADE.  Cascading actions for InnoDB  tables on the source are executed on the replica only  if the tables sharing the foreign key relation use InnoDB  on both the source and replica. This is true whether you are using statement-based or row-based replication. Suppose that you have started replication, and then create two tables on the source, where InnoDB  is defined as the default storage engine, using the following CREATE TABLE  statements: 

CREATE TABLE fc1 ( i INT PRIMARY KEY, j INT ); CREATE TABLE fc2 ( m INT PRIMARY KEY, n INT, FOREIGN KEY ni (n) REFERENCES fc1 (i) ON DELETE CASCADE ); 

If the replica has MyISAM  defined as the default storage engine, the same tables are created on the replica, but they use the MyISAM  storage engine, and the FOREIGN KEY  option is ignored. Now we insert some rows into the tables on the source: 

source> INSERT INTO fc1 VALUES (1, 1), (2, 2); Query OK, 2 rows affected (0.09 sec) Records: 2 Duplicates: 0 Warnings: 0 source> INSERT INTO fc2 VALUES (1, 1), (2, 2), (3, 1); 

