This section describes the status variables providing information about Group Replication.
With the exception of
the name of each Group Replication status variable is prefixed
The status variables and their meanings are listed here:
Shows the primary member UUID when the group is operating in single-primary mode. If the group is operating in multi-primary mode, shows an empty string.Warning
group_replication_primary_memberstatus variable has been deprecated. Expect it to be removed in a future version of MySQL.
Number of control messages sent by this member.
Sum of the number of bytes used in control messages sent by this member; this is the on-the-wire size.
Sum of the round-trip times in microseconds for control messages sent by this member; a round trip is measured between the sending and the delivery of the message on the sender. This should provide the time between sending and delivery of control messages for the majority of the members of the group, including the sender.
This is the nmber of transaction data messages sent by this member.
Sum in bytes used by data messages sent by this member; this is the on-the-wire size.
Sum of the round-trip times in microseconds for data messages sent by this member; a round trip is measured between the sending and the delivery of the message on the sender. This should provide the time between sending and delivery of data messages for the majority of the members of the group, including the sender.
The number of transactions executed with
Sum of the time in microseconds between delivery of the transaction executed with
BEFORE_AND_AFTER, and acknowledgement by the other group members that the transaction is prepared.
This value does not include transaction send roundtrip time.
Number of transactions executed with
Sum of the time in microseconds that the member waited until its group replication applier channel was consumed before executing the transaction with
Number of transactions on secondaries that waited to start, while waiting for transactions from the primary with
BEFORE_AND_AFTERto be committed.
Sum of the times in microseconds that transactions on secondaries waited on transactions from the primary with
BEFORE_AND_AFTERto be committed, before starting.
The number of times certification garbage collection has been run.
Sum of the times in microseconds taken by certification garbage collection.
Sum of all proposals that were initiated and terminated on this node.
Sum of all empty proposal rounds that were initiated and terminated on this node.
Sum of all socket-level bytes originating on this node that were sent to all (other) group nodes. More data is reported here than for sent messages, since they are multiplexed and sent to each member.
For example, if we have a group with three members and we send a 100-byte message, this value accounts for 300 bytes, since we send 100 bytes to each node.
The total elapsed time for all consensus rounds started and finished on this node. By comparing this value with
Gr_all_consensus_proposals_count, we can determine whether a given consensus time has an upward trend, which may signal a problem.
The number of full 3-phase rounds that this node has initiated. If this number grows over time, it means that at least one node is having problems answering to proposals, either due to something it to run slowly, or to network issues. Use this value together with the
count_member_failure_suspicionscolumn of the Performance Schema
replication_group_communication_informationtable when diagnosing such issues.
The number of high-level messages sent by this node to the group. These are the messages received from the API for proposing to the group. The XCom batching mechanism batches these messages and proposes them all together. The value shown for this variable reflects the number of messages prior to batching.
The sum of all socket-level bytes received from group nodes having this node as a destination.
The time when the last consensus proposal was approved, in a timestamp format. This can be an indicator whether the group is making slow progress, or has halted.
These status variables all have member scope since they reflect what the local member observes. They are reset on group bootstrap, joining of a new member, automatic rejoin of an existing member, and server restart.
All of the status variables just listed (with the exception of
were added in MySQL 8.1.0.