<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-group-membership">
      </a>
      20.1.4.1 Group Membership
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045134392208">
  </a>
  <a class="indexterm" name="idm46045134390720">
  </a>
  <a class="indexterm" name="idm46045134389232">
  </a>
  <p>
   In MySQL Group Replication, a set of servers forms a replication
        group. A group has a name, which takes the form of a UUID. The
        group is dynamic and servers can leave (either voluntarily or
        involuntarily) and join it at any time. The group adjusts itself
        whenever servers join or leave.
  </p>
  <p>
   If a server joins the group, it automatically brings itself up
        to date by fetching the missing state from an existing server.
        If a server leaves the group, for instance it was taken down for
        maintenance, the remaining servers notice that it has left and
        reconfigure the group automatically.
  </p>
  <p>
   Group Replication has a group membership service that defines
        which servers are online and participating in the group. The
        list of online servers is referred to as a
   <span class="emphasis">
    <em>
     view
    </em>
   </span>
   . Every server in the group has a
        consistent view of which servers are the members participating
        actively in the group at a given moment in time.
  </p>
  <p>
   Group members must agree not only on transaction commits, but
        also on which is the current view. If existing members agree
        that a new server should become part of the group, the group is
        reconfigured to integrate that server in it, which triggers a
        view change. If a server leaves the group, either voluntarily or
        not, the group dynamically rearranges its configuration and a
        view change is triggered.
  </p>
  <p>
   In the case where a member leaves the group voluntarily, it
        first initiates a dynamic group reconfiguration, during which
        all members have to agree on a new view without the leaving
        server. However, if a member leaves the group involuntarily, for
        example because it has stopped unexpectedly or the network
        connection is down, it cannot initiate the reconfiguration. In
        this situation, Group Replication's failure detection mechanism
        recognizes after a short period of time that the member has
        left, and a reconfiguration of the group without the failed
        member is proposed. As with a member that leaves voluntarily,
        the reconfiguration requires agreement from the majority of
        servers in the group. However, if the group is not able to reach
        agreement, for example because it partitioned in such a way that
        there is no majority of servers online, the system is not able
        to dynamically change the configuration, and blocks to prevent a
        split-brain situation. This situation requires intervention from
        an administrator.
  </p>
  <p>
   It is possible for a member to go offline for a short time, then
        attempt to rejoin the group again before the failure detection
        mechanism has detected its failure, and before the group has
        been reconfigured to remove the member. In this situation, the
        rejoining member forgets its previous state, but if other
        members send it messages that are intended for its pre-crash
        state, this can cause issues including possible data
        inconsistency. If a member in this situation participates in
        XCom's consensus protocol, it could potentially cause XCom to
        deliver different values for the same consensus round, by making
        a different decision before and after failure.
  </p>
  <p>
   To counter this possibility, MySQL Group Replication checks for
        the situation where a new incarnation of the same server is
        trying to join the group while its old incarnation (with the
        same address and port number) is still listed as a member. The
        new incarnation is blocked from joining the group until the old
        incarnation can be removed by a reconfiguration. Note that if a
        waiting period has been added by the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_member_expel_timeout">
    <code class="literal">
     group_replication_member_expel_timeout
    </code>
   </a>
   system variable to allow additional time for members to
        reconnect with the group before they are expelled, a member
        under suspicion can become active in the group again as its
        current incarnation if it reconnects to the group before the
        suspicion times out. When a member exceeds the expel timeout and
        is expelled from the group, or when Group Replication is stopped
        on the server by a
   <a class="link" href="stop-group-replication.html" title="15.4.3.2 STOP GROUP_REPLICATION Statement">
    <code class="literal">
     STOP
        GROUP_REPLICATION
    </code>
   </a>
   statement or a server failure, it
        must rejoin as a new incarnation.
  </p>
 </div>
 <br/>
</div>
