Documentation Home
MySQL 9.1 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.4Mb
PDF (A4) - 40.5Mb
Man Pages (TGZ) - 259.5Kb
Man Pages (Zip) - 366.7Kb
Info (Gzip) - 4.1Mb
Info (Zip) - 4.1Mb


MySQL 9.1 Reference Manual  / ...  / MySQL Performance Schema  / Performance Schema Table Descriptions  /  Performance Schema Replication Tables

29.12.11 Performance Schema Replication Tables

29.12.11.1 The binary_log_transaction_compression_stats Table
29.12.11.2 The replication_applier_configuration Table
29.12.11.3 The replication_applier_filters Table
29.12.11.4 The replication_applier_global_filters Table
29.12.11.5 The replication_applier_metrics Table
29.12.11.6 The replication_applier_progress_by_worker Table
29.12.11.7 The replication_applier_status Table
29.12.11.8 The replication_applier_status_by_coordinator Table
29.12.11.9 The replication_applier_status_by_worker Table
29.12.11.10 The replication_asynchronous_connection_failover Table
29.12.11.11 The replication_asynchronous_connection_failover_managed Table
29.12.11.12 The replication_connection_configuration Table
29.12.11.13 The replication_connection_status Table
29.12.11.14 The replication_group_communication_information Table
29.12.11.15 The replication_group_configuration_version Table
29.12.11.16 The replication_group_member_actions Table
29.12.11.17 The replication_group_member_stats Table
29.12.11.18 The replication_group_members Table

The Performance Schema provides tables that expose replication information. This is similar to the information available from theSHOW REPLICA STATUS statement, but representation in table form is more accessible and has usability benefits:

  • SHOW REPLICA STATUS output is useful for visual inspection, but not so much for programmatic use. By contrast, using the Performance Schema tables, information about replica status can be searched using generalSELECT queries, including complexWHERE conditions, joins, and so forth.

  • Query results can be saved in tables for further analysis, or assigned to variables and thus used in stored procedures.

  • The replication tables provide better diagnostic information. For multithreaded replica operation,SHOW REPLICA STATUS reports all coordinator and worker thread errors using theLast_SQL_Errno andLast_SQL_Error fields, so only the most recent of those errors is visible and information can be lost. The replication tables store errors on a per-thread basis without loss of information.

  • The last seen transaction is visible in the replication tables on a per-worker basis. This is information not available fromSHOW REPLICA STATUS.

  • Developers familiar with the Performance Schema interface can extend the replication tables to provide additional information by adding rows to the tables.

Replication Table Descriptions

The Performance Schema provides the following replication-related tables:

The following Performance Schema replication tables continue to be populated when the Performance Schema is disabled:

The exception is local timing information (start and end timestamps for transactions) in the replication tablesreplication_connection_status,replication_applier_status_by_coordinator, andreplication_applier_status_by_worker. This information is not collected when the Performance Schema is disabled.

The following sections describe each replication table in more detail, including the correspondence between the columns produced bySHOW REPLICA STATUS and the replication table columns in which the same information appears.

The remainder of this introduction to the replication tables describes how the Performance Schema populates them and which fields fromSHOW REPLICA STATUS are not represented in the tables.

Replication Table Life Cycle

The Performance Schema populates the replication tables as follows:

  • Prior to execution ofCHANGE REPLICATION SOURCE TO, the tables are empty.

  • AfterCHANGE REPLICATION SOURCE TO, the configuration parameters can be seen in the tables. At this time, there are no active replication threads, so theTHREAD_ID columns areNULL and theSERVICE_STATE columns have a value ofOFF.

  • AfterSTART REPLICA, non-nullTHREAD_ID values can be seen. Threads that are idle or active have aSERVICE_STATE value ofON. The thread that connects to the source has a value ofCONNECTING while it establishes the connection, andON thereafter as long as the connection lasts.

  • AfterSTOP REPLICA, theTHREAD_ID columns becomeNULL and theSERVICE_STATE columns for threads that no longer exist have a value ofOFF.

  • The tables are preserved afterSTOP REPLICA or threads stopping due to an error.

  • Thereplication_applier_status_by_worker table is nonempty only when the replica is operating in multithreaded mode. That is, if thereplica_parallel_workers system variable is greater than 0, this table is populated whenSTART REPLICA is executed, and the number of rows shows the number of workers.

Replica Status Information Not In the Replication Tables

The information in the Performance Schema replication tables differs somewhat from the information available fromSHOW REPLICA STATUS because the tables are oriented toward use of global transaction identifiers (GTIDs), not file names and positions, and they represent server UUID values, not server ID values. Due to these differences, severalSHOW REPLICA STATUS columns are not preserved in the Performance Schema replication tables, or are represented a different way:

  • The following fields refer to file names and positions and are not preserved:

    Master_Log_FileRead_Master_Log_PosRelay_Log_FileRelay_Log_PosRelay_Master_Log_FileExec_Master_Log_PosUntil_ConditionUntil_Log_FileUntil_Log_Pos

  • TheMaster_Info_File field is not preserved. It refers to themaster.info file used for the replica's source metadata repository, which has been superseded by the use of crash-safe tables for the repository.

  • The following fields are based onserver_id, notserver_uuid, and are not preserved:

    Master_Server_IdReplicate_Ignore_Server_Ids

  • TheSkip_Counter field is based on event counts, not GTIDs, and is not preserved.

  • These error fields are aliases forLast_SQL_Errno andLast_SQL_Error, so they are not preserved:

    Last_ErrnoLast_Error

    In the Performance Schema, this error information is available in theLAST_ERROR_NUMBER andLAST_ERROR_MESSAGE columns of thereplication_applier_status_by_worker table (andreplication_applier_status_by_coordinator if the replica is multithreaded). Those tables provide more specific per-thread error information than is available fromLast_Errno andLast_Error.

  • Fields that provide information about command-line filtering options is not preserved:

    Replicate_Do_DBReplicate_Ignore_DBReplicate_Do_TableReplicate_Ignore_TableReplicate_Wild_Do_TableReplicate_Wild_Ignore_Table

  • TheReplica_IO_State andReplica_SQL_Running_State fields are not preserved. If needed, these values can be obtained from the process list by using theTHREAD_ID column of the appropriate replication table and joining it with theID column in theINFORMATION_SCHEMAPROCESSLIST table to select theSTATE column of the latter table.

  • TheExecuted_Gtid_Set field can show a large set with a great deal of text. Instead, the Performance Schema tables show GTIDs of transactions that are currently being applied by the replica. Alternatively, the set of executed GTIDs can be obtained from the value of thegtid_executed system variable.

  • TheSeconds_Behind_Master andRelay_Log_Space fields are in to-be-decided status and are not preserved.

Replication Channels

The first column of the replication Performance Schema tables isCHANNEL_NAME. This enables the tables to be viewed per replication channel. In a non-multisource replication setup there is a single default replication channel. When you are using multiple replication channels on a replica, you can filter the tables per replication channel to monitor a specific replication channel. SeeSection 19.2.2, “Replication Channels” andSection 19.1.5.8, “Monitoring Multi-Source Replication” for more information.