• group_replication_recovery  - This channel is used for the replication changes that are related to the distributed recovery phase. 

• group_replication_applier  - This channel is used for the incoming changes from the group. This is the channel used to apply transactions coming directly from the group. 

From MySQL 8.0.21, Group Replication lifecycle events that are non-error situations are classified as system messages, and are always logged to the server’s error log on a replication group member. You can use this information to review the history of the server’s membership in a replication group. In previous releases, Group Replication lifecycle events that are non-error situations are classified as information messages, which can be added to the error log by specifying a log_error_verbosity  level of 3 for the server. 

Some lifecycle events that affect the whole group are logged on every group member, such as a new member entering ONLINE  status in the group or a primary election. Other events are logged only on the member where they take place, such as super read only mode being enabled or disabled on the member, or the member leaving the group. A number of lifecycle events that can indicate an issue if they occur frequently are logged as warning messages, including the member becoming unreachable and reachable again, and the member starting distributed recovery by state transfer from the binary log or by a remote cloning operation. 

## 18.4.1 GTIDs and Group Replication 

Group Replication uses GTIDs (global transaction identifiers) to track exactly which transactions have been committed on every server instance. The settings gtid_mode=ON  and enforce_gtid_consistency=ON  are required on all group members. Incoming transactions from clients are assigned a GTID by the group member that receives them. Any replicated transactions that are received by group members on asynchronous replication channels from source servers outside the group retain the GTIDs that they have when they arrive on the group member. 

The GTIDs that are assigned to incoming transactions from clients use the group name specified by the group_replication_group_name  system variable as the UUID part of the identifier, rather than the server UUID of the individual group member that received the transaction. All the transactions received directly by the group can therefore be identified and are grouped together in GTID sets, and it does not matter which member originally received them. Each group member has a block of consecutive GTIDs reserved for its use, and when these are consumed it reserves more. The group_replication_gtid_assignment_block_size  system variable sets the size of the blocks, with a default of 1 million GTIDs in each block. 

View change events ( View_change_log_event ), which are generated by the group itself when a new member joins, are given GTIDs when they are recorded in the binary log. By default, the GTIDs for these events also use the group name specified by the group_replication_group_name  system variable as the UUID part of the identifier. From MySQL 8.0.26, you can set the Group Replication system variable group_replication_view_change_uuid  to use an alternative UUID in the GTIDs for view change events, so that they are easy to distinguish from transactions received by the group from clients. This can be useful if your setup allows for failover between groups, and you need to identify and discard transactions that were specific to the backup group. The alternative UUID must be different from the server UUIDs of the members. It must also be different from any UUIDs in the GTIDs applied to anonymous transactions using the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS  option of the CHANGE REPLICATION SOURCE TO  statement. 

## 18.4.2 Group Replication Server States 

There are various states that a server instance can be in. If servers are communicating properly, all report the same states for all servers. However, if there is a network partition, or a server leaves the group, 

