replication_group_members is updated
whenever there is a view change, for example when the
configuration of the group is dynamically changed. At that point,
servers exchange some of their metadata to synchronize themselves
and continue to cooperate together.
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, then different information may be reported, depending on which server is queried. Note that if the server has left the group then obviously it cannot report updated information about other servers' state. If there is a partition, such that quorum is lost, servers are not able to coordinate between themselves. As a consequence, they cannot guess what the status of different servers is. Therefore, instead of guessing their state they report that some servers are unreachable.
Table 18.5 Server State
The member is ready to serve as a fully functional group member, meaning that the client can connect and start executing transactions.
The member is in the process of becoming an active member of the group and is currently going through the recovery process, receiving state information from a donor.
The plugin is loaded but the member does not belong to any group.
The state of the member. Whenever there is an error on the recovery phase or while applying changes, the server enters this state.
Whenever the local failure detector suspects that a given server is not reachable, because maybe it has crashed or was disconnected involuntarily, it shows that server's state as 'unreachable'.
Note that Group Replication is not synchronous, but eventually synchronous. More precisely, transactions are delivered to all group members in the same order, but their execution is not synchronized, meaning that after a transaction is accepted to be committed, each member commits at its own pace.