副本服务器创建两个复制元数据存储库，连接元数据存储库和应用程序元数据存储库。复制元数据存储库在副本服务器关闭后仍然存在。如果使用基于二进制日志文件位置的复制，则在副本重新启动时，它会读取这两个存储库以确定它之前在从源读取二进制日志和处理自身中继日志方面已经进行到哪里。如果使用基于 GTID 的复制，副本不会将复制元数据存储库用于该目的，但需要它们来获取它们包含的其他元数据。

连接元数据存储库写入 mysql 系统模式中的 slave_master_info 表，应用程序元数据存储库写入 mysql 系统模式中的 slave_relay_log_info 表。如果 mysqld 无法初始化复制元数据存储库的表，则会发出警告消息，但副本仍允许继续启动。这种情况最有可能发生在从不支持使用表作为存储库的 MySQL 版本升级到支持使用表的版本时。

RESET REPLICA 清除复制元数据存储库中的数据，但复制连接参数除外（取决于 MySQL Server 版本）。有关详细信息，请参见 RESET REPLICA 的说明。

您可以设置 CHANGE REPLICATION SOURCE TO 语句的 GTID_ONLY 选项，以阻止复制通道将文件名和文件位置持久保存到复制元数据存储库中。这避免了在基于 GTID 的复制实际上不需要它们的情况下写入和读取表。使用 GTID_ONLY 设置，当副本对事务中的事件进行排队和应用，或者当复制线程停止和启动时，不会更新连接元数据存储库和应用程序元数据存储库。文件位置在内存中跟踪，如果需要，可以使用 SHOW REPLICA STATUS 查看。只有在以下情况下才会同步复制元数据存储库

将复制元数据存储库创建为表是默认设置；使用文件已被弃用。

mysql.slave_master_info 和 mysql.slave_relay_log_info 表使用 InnoDB 事务性存储引擎创建。对应用程序元数据存储库表的更新与事务一起提交，这意味着记录在该存储库中的副本的进度信息始终与已应用于数据库的内容一致，即使在意外服务器停止的情况下也是如此。有关副本上设置组合的信息，这些设置对于意外停止最具弹性，请参见 第 19.4.2 节，“处理副本的意外停止”。

当您备份副本数据或传输其数据的快照以创建新的副本时，请确保您包含包含复制元数据存储库的 mysql.slave_master_info 和 mysql.slave_relay_log_info 表。对于克隆操作，请注意，当复制元数据存储库被创建为表时，它们在克隆操作期间被复制到接收方，但是当它们被创建为文件时，它们不会被复制。当使用基于二进制日志文件位置的复制时，复制元数据存储库是必需的，以便在重新启动恢复的、复制的或克隆的副本后恢复复制。如果您没有中继日志文件，但仍然有应用程序元数据存储库，您可以检查它以确定复制 SQL 线程在源的二进制日志中执行了多远。然后，您可以使用带有 SOURCE_LOG_FILE 和 SOURCE_LOG_POS 选项的 CHANGE REPLICATION SOURCE TO 语句来告诉副本从该点重新读取源的二进制日志（前提是源上仍然存在所需的二进制日志）。

另一个存储库，应用程序工作程序元数据存储库，主要用于内部使用，并保存有关多线程副本上的工作程序线程的状态信息。应用程序工作程序元数据存储库包含每个工作程序线程的中继日志文件和源的二进制日志文件的名和位置。如果应用程序元数据存储库被创建为表，这是默认设置，应用程序工作程序元数据存储库将被写入 mysql.slave_worker_info 表。如果应用程序元数据存储库被写入文件，应用程序工作程序元数据存储库将被写入 worker-relay-log.info 文件。对于外部使用，工作程序线程的状态信息在 Performance Schema replication_applier_status_by_worker 表中显示。

复制元数据存储库最初包含的信息类似于 SHOW REPLICA STATUS 语句输出中显示的信息，这在 第 15.4.2 节，“控制副本服务器的 SQL 语句” 中进行了讨论。从那时起，复制元数据存储库中添加了更多信息，这些信息没有在 SHOW REPLICA STATUS 语句中显示。

对于连接元数据存储库，下表显示了 mysql.slave_master_info 表中的列、SHOW REPLICA STATUS 显示的列以及弃用的 master.info 文件中的行之间的对应关系。

对于应用程序元数据存储库，下表显示了 mysql.slave_relay_log_info 表中的列、SHOW REPLICA STATUS 显示的列以及弃用的 relay-log.info 文件中的行之间的对应关系。