副本服务器创建两个复制元数据存储库：连接元数据存储库和应用元数据存储库。复制元数据存储库会在副本服务器关闭后保留下来。如果使用基于二进制日志文件位置的复制，当副本重启时，它会读取这两个存储库以确定它之前在从源读取二进制日志和处理其自身中继日志的过程中已经进行到哪里。如果使用基于 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 查看。复制元数据存储库仅在以下情况下同步

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

使用 InnoDB 事务存储引擎创建 mysql.slave_master_info 和 mysql.slave_relay_log_info 表。对应用程序元数据存储库表的更新与事务一起提交，这意味着该存储库中记录的副本进度信息始终与已应用到数据库的内容一致，即使在意外服务器停止的情况下也是如此。有关副本上最能抵御意外停止的设置组合的信息，请参阅 第 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 文件。对于外部使用，工作线程的状况信息在性能模式 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 文件中的行之间的对应关系。