MySQL 5.7 Release Notes
Each member in a replication group certifies and applies transactions committed by the group. Statistics regarding the certifier and applier procedures are useful to understand how the applier queue is growing, how many conflicts have been found, how many transactions were checked, which transactions are committed everywhere, and so on.
The
performance_schema.replication_group_member_stats
table provides information related to the certification process.
The information is shared between all the server instances that
are members of the replication group, so information on all the
group members can be queried from any member.
Table 17.1 replication_group_member_stats
Field | Description |
|---|---|
Channel_name | The name of the Group Replication channel. |
Member_id | The member server UUID. This has a different value for each member in the group. This also serves as a key since it is unique to each member. |
Count_transactions_in_queue | The number of transactions in the queue pending conflict detection checks. Once the transactions have been checked for conflicts, if they pass the check, they are queued to be applied as well. |
Count_transactions_checked | The number of transactions that have been checked for conflicts. |
Count_conflicts_detected | The number of transactions that did not pass the conflict detection check. |
Count_transactions_rows_validating | The current size of the conflict detection database (against which each transaction is certified). |
Transactions_committed_all_members | The transactions that have been successfully committed on all members of the replication group. This is updated at a fixed time interval. |
Last_conflict_free_transaction | The transaction identifier of the last conflict free transaction checked. |
These fields are important for monitoring the performance of the members connected in the group. For example, suppose that one of the group’s members is delayed and is not able to keep up to date with the other members of the group. In this case you might see a large number of transactions in the queue. Based on this information, you could decide to either remove the member from the group, or delay the processing of transactions on the other members of the group in order to reduce the number of queued transactions. This information can also help you to decide how to adjust the flow control of the Group Replication plugin.