MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
A replica server creates several repositories of information to use for the replication process:
The replica's relay log, which is written by the replication I/O thread, contains the transactions read from the replication source server's binary log. The transactions in the relay log are applied on the replica by the replication SQL thread. For information about the relay log, see Section 17.2.2.1, “The Relay Log”.
The replica's connection metadata
repository contains information that the
replication I/O thread needs to connect to the replication
source server and retrieve transactions from the source's
binary log. The connection metadata repository is written to
the master.info
file or to the
mysql.slave_master_info
table.
The replica's applier metadata repository
contains information that the replication SQL thread needs to
read and apply transactions from the replica's relay log. The
applier metadata repository is written to the
relay-log.info
file or to the
mysql.slave_relay_log_info
table.
The connection metadata repository and applier metadata repository are collectively known as the replication metadata repositories. For information about these, see Section 17.2.2.2, “Replication Metadata Repositories”.
The mysql.slave_master_info
and
mysql.slave_relay_log_info
tables are created
using the transactional storage engine
InnoDB
. Updates to the replica's
applier metadata repository table are committed together with the
transactions, meaning that the replica's progress information
recorded in that repository is always consistent with what has
been applied to the database, even in the event of an unexpected
server halt. The
--relay-log-recovery
option must be
enabled on the replica to guarantee resilience. For more details,
see
Section 17.3.2, “Handling an Unexpected Halt of a Replica Server”.