Distributed Recovery If the joining member left the group unintentionally, so in any situation listed above except the last, it proceeds to take the action specified by the  group_replication_exit_state_action  system variable. When Group Replication’s distributed recovery process is carrying out state transfer from the binary log, to synchronize the joining member with the donor up to a specific point in time, the joining member and donor make use of GTIDs (see Section 17.1.3, “Replication with Global Transaction Identifiers” ). However, GTIDs only provide a means to realize which transactions the joining member is missing. They do not help marking a specific point in time to which the server joining the group must catch up, nor do they convey certification information. This is the job of binary log view markers, which mark view changes in the binary log stream, and also contain additional metadata information, supplying the joining member with missing certification-related data. This topic explains the role of view changes and the view change identifier, and the steps to carry out state transfer from the binary log. A  view  corresponds to a group of members participating actively in the current configuration, in other words at a specific point in time. They are functioning correctly and online in the group. A  view change  occurs when a modification to the group configuration happens, such as a member joining or leaving. Any group membership change results in an independent view change communicated to all members at the same logical point in time. A  view identifier  uniquely identifies a view. It is generated whenever a view change happens. At the group communication layer, view changes with their associated view identifiers mark boundaries between the data exchanged before and after a member joins. This concept is implemented through a binary log event: the"view change log event". The view identifier is recorded to demarcate transactions transmitted before and after changes happen in the group membership. The view identifier itself is built from two parts: a randomly generated part, and a monotonically increasing integer. The randomly generated part is generated when the group is created, and remains unchanged while there is at least one member in the group. The integer is incremented every time a view change happens. Using these two different parts enables the view identifier to identify incremental group changes caused by members joining or leaving, and also to identify the situation where all members leave the group in a full group shutdown, so no information remains of what view the group was in. Randomly generating part of the identifier when the group is started from the beginning ensures that the data markers in the binary log remain unique, and an identical identifier is not reused after a full group shutdown, as this would cause issues with distributed recovery in the future. All servers are online and processing incoming transactions from the group. Some servers may be a little behind in terms of transactions replicated, but eventually they converge. The group acts as one distributed and replicated database. 3746 • Joining member leaves the group  - The joining member leaves the group or Group Replication is stopped on the joining member while state transfer is in progress. 18.5.3.5 How Distributed Recovery Works View and View Changes Begin: Stable Group