25.12.11 性能架构复制 table

• 25 .12.11.1 复制连接配置 table

• 25 .12.11.2 Replication_Connection_Statustable

• 25 .12.11.3 Replication_applier_configurationtable

• 25 .12.11.4 Replication_applier_statustable

• 25 .12.11.5 Replication_applier_status_by_coordinatortable

• 25 .12.11.6 Replication_applier_status_by_workertable

• 25 .12.11.7 Replication_group_memberstable

• 25 .12.11.8 Replication_Group_member_statstable

性能架构提供了一些 table，这些 table 公开了复制信息。这类似于显示从站状态语句中提供的信息，但是 table 形式的 table 示更易于访问，并且具有可用性优势：

• 显示从站状态输出对于外观检查很有用，但对于程序使用而言却没那么多。相比之下，使用 Performance Schematable，可以使用常规SELECT查询(包括复杂的WHERE条件，联接等)来搜索有关副本状态的信息。

• 查询结果可以保存在 table 中以进行进一步分析，或分配给变量，从而在存储过程中使用。

• 复制 table 提供了更好的诊断信息。对于多线程副本操作，显示从站状态使用Last_SQL_Errno和Last_SQL_Error字段报告所有协调器线程和工作线程错误，因此只有这些错误中的最新错误才可见，并且信息可能丢失。复制 table 按线程存储错误，而不会丢失信息。

• 在每个工作人员的基础上，最后看到的事务在复制 table 中可见。这是无法从显示从站状态获得的信息。

• 熟悉 Performance Schema 界面的开发人员可以通过向 table 添加行来扩展复制 table，以提供其他信息。

复制 table 说明

性能架构提供以下与复制相关的 table：

• 包含有关副本到复制源服务器的连接信息的 table：

• replication_connection_configuration：用于连接到源的配置参数

  • replication_connection_status：到源的当前连接状态

• 包含有关事务处理应用程序的常规(非特定于线程)信息的 table：

• replication_applier_configuration：副本上事务处理程序的配置参数。

  • replication_applier_status：副本上事务处理应用程序的当前状态。

• 包含有关负责应用从源接收到的事务的特定线程的信息的 table：

• replication_applier_status_by_coordinator：协调线程的状态(除非副本为多线程，否则为空)。

  • replication_applier_status_by_worker：如果副本是多线程的，则应用程序线程或辅助线程的状态。

• 包含有关复制组成员信息的 table：

• replication_group_members：为组成员提供网络和状态信息。

  • replication_group_member_stats：提供有关组成员及其参与的 Transaction 的统计信息。

以下各节将更详细地描述每个复制 table，包括由显示从站状态产生的列与其中显示相同信息的复制 table 列之间的对应关系。

复制 table 简介的其余部分描述了性能模式如何填充它们以及 table 中未 table 示显示从站状态的哪些字段。

复制 table 生命周期

性能架构按以下方式填充复制 table：

• 在执行更改为主之前，table 为空。

• 在更改为主之后，可以在 table 中看到配置参数。目前，没有活动的副本线程，因此THREAD_ID列为NULL，而SERVICE_STATE列的值为OFF。

• 在START SLAVE之后，可以看到非NULL THREAD_ID的值。空闲或活动的线程的SERVICE_STATE值为ON。构建连接时，连接到源的线程的值为CONNECTING，此后只要连接持续，其值为ON。

• 在STOP SLAVE之后，THREAD_ID列变为NULL，而不再存在的线程的SERVICE_STATE列的值为OFF。

• 这些 table 在STOP SLAVE或线程由于错误而死后被保留。

• 仅当副本在多线程模式下运行时，replication_applier_status_by_workertable 才是非空的。也就是说，如果slave_parallel_workers系统变量大于 0，则在执行START SLAVE时将填充此 table，并且行数显示了工作程序数。

显示从站状态信息不在复制 table 中

性能模式复制 table 中的信息与显示从站状态中可用的信息有所不同，因为这些 table 是针对使用全局事务标识符(GTID)而非文件名和位置的，并且它们 table 示服务器 UUID 值，而不是服务器 ID 值。由于这些差异，Performance Schema 复制 table 中未保留几个显示从站状态列，或者以不同的方式 table 示它们：

• 以下字段引用文件名和位置，并且不保留：

Master_Log_File
Read_Master_Log_Pos
Relay_Log_File
Relay_Log_Pos
Relay_Master_Log_File
Exec_Master_Log_Pos
Until_Condition
Until_Log_File
Until_Log_Pos

• Master_Info_File字段未保留。它指的是master.info文件，该文件已被崩溃安全 table 取代。

• 以下字段基于server_id而不是server_uuid，并且不保留：

Master_Server_Id
Replicate_Ignore_Server_Ids

• Skip_Counter字段基于事件计数而不是 GTID，因此不会保留。

• 这些错误字段是Last_SQL_Errno和Last_SQL_Error的别名，因此不会保留它们：

Last_Errno
Last_Error

在性能架构中，此错误信息在replication_applier_status_by_workertable 的LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE列(如果副本是多线程的，则在replication_applier_status_by_coordinator)中可用。与Last_Errno和Last_Error相比，这些 table 提供了更具体的每线程错误信息。

• 提供有关命令行过滤选项信息的字段不会保留：

Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table

• Slave_IO_State和Slave_SQL_Running_State字段不会保留。如果需要，可以通过使用适当的复制 table 的THREAD_ID列并将其与INFORMATION_SCHEMA PROCESSLISTtable 中的ID列连接起来以选择后者的STATE列，从进程列 table 中获取这些值。

• Executed_Gtid_Set字段可以显示大量文本。而是，性能架构 table 显示了副本当前正在应用的事务的 GTID。或者，可以从gtid_executed系统变量的值获得一组已执行的 GTID。

• Seconds_Behind_Master和Relay_Log_Space字段处于待定状态，未保留。

状态变量移至复制 table

从 MySQL 版本 5.7.5 开始，以下状态变量(以前使用SHOW STATUS进行监视)已移至 Perfomance Schema 复制 table：

• Slave_retried_transactions

• Slave_last_heartbeat

• Slave_received_heartbeats

• Slave_heartbeat_period

• Slave_running

这些状态变量现在仅在使用单个复制通道时才相关，因为它们仅报告默认复制通道的状态。当存在多个复制通道时，请使用本节中介绍的性能架构复制 table，这些 table 报告每个现有复制通道的这些变量。

Replication Channels

复制性能架构 table 的第一列是CHANNEL_NAME。这样可以按复制通道查看 table。在非多源复制设置中，只有一个默认复制通道。当您在副本上使用多个复制通道时，可以筛选每个复制通道的 table 以监视特定的复制通道。有关更多信息，请参见第 16.2.3 节“复制通道”和第 16.1.5.8 节，“多源复制监视”。