MySQL 8.4 Release Notes
副本服务器会创建多个信息存储库，用于复制过程：A replica server creates several repositories of information to use for the replication process:
副本的中继日志由复制 I/O（接收器）线程写入，包含从复制源服务器的二进制日志中读取的事务。中继日志中的事务由复制 SQL（应用器）线程在副本上应用。有关中继日志的信息，请参见第 19.2.4.1 节，“中继日志”。The replica's relay log, which is written by the replication I/O (receiver) 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 (applier) thread. For information about the relay log, see Section 19.2.4.1, “The Relay Log”.
副本的连接元数据存储库包含复制接收线程连接到复制源服务器并从源的二进制日志中检索事务所需的信息。连接元数据存储库写入到
mysql.slave_master_info表中。The replica's connection metadata repository contains information that the replication receiver 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 themysql.slave_master_infotable.副本的应用程序元数据存储库包含复制应用程序线程需要读取并从副本的中继日志应用事务的信息。应用程序元数据存储库写入到
mysql.slave_relay_log_info表中。The replica's applier metadata repository contains information that the replication applier thread needs to read and apply transactions from the replica's relay log. The applier metadata repository is written to themysql.slave_relay_log_infotable.
副本的连接元数据存储库和应用程序元数据存储库统称为复制元数据存储库。有关这些的详细信息，请参见第 19.2.4.2 节，“复制元数据存储库”。The replica's connection metadata repository and applier metadata repository are collectively known as the replication metadata repositories. For information about these, see Section 19.2.4.2, “Replication Metadata Repositories”.
让复制能够抵御意外中断。 mysql.slave_master_info 和 mysql.slave_relay_log_info 表使用事务性存储引擎 InnoDB 创建。副本的应用程序元数据存储表的更新会与事务一起提交，这意味着即使发生意外的服务器中断，存储在该存储库中的副本进度信息也始终与已应用到数据库的内容一致。有关在副本上实现最能抵御意外中断的设置组合的信息，请参阅 第 19.4.2 节，“处理副本的意外中断”。Making replication resilient to unexpected halts.
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. For information on the combination of
settings on the replica that is most resilient to unexpected
halts, see
Section 19.4.2, “Handling an Unexpected Halt of a Replica”.