<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-summary">
      </a>
      20.1.1.2 Group Replication
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045134550768">
  </a>
  <p>
   Group Replication is a technique that can be used to implement
        fault-tolerant systems. A replication group is a set of servers,
        each of which has a complete copy of the data (a shared-nothing
        replication scheme), which interact with each other through
        message passing. The communication layer provides a set of
        guarantees such as atomic message and total order message
        delivery. These are very powerful properties that translate into
        very useful abstractions that one can resort to build more
        advanced database replication solutions.
  </p>
  <p>
   MySQL Group Replication builds on top of such properties and
        abstractions and implements a multi-source update everywhere
        replication protocol. A replication group is formed by multiple
        servers; each server in the group may execute transactions
        independently at any time. Read/write transactions commit only
        after they have been approved by the group. In other words, for
        any read/write transaction the group needs to decide whether it
        commits or not, so the commit operation is not a unilateral
        decision from the originating server. Read-only transactions
        need no coordination within the group and commit immediately.
  </p>
  <p>
   When a read/write transaction is ready to commit at the
        originating server, the server atomically broadcasts the write
        values (the rows that were changed) and the corresponding write
        set (the unique identifiers of the rows that were updated).
        Because the transaction is sent through an atomic broadcast,
        either all servers in the group receive the transaction or none
        do. If they receive it, then they all receive it in the same
        order with respect to other transactions that were sent before.
        All servers therefore receive the same set of transactions in
        the same order, and a global total order is established for the
        transactions.
  </p>
  <p>
   However, there may be conflicts between transactions that
        execute concurrently on different servers. Such conflicts are
        detected by inspecting and comparing the write sets of two
        different and concurrent transactions, in a process called
   <span class="emphasis">
    <em>
     certification
    </em>
   </span>
   . During certification,
        conflict detection is carried out at row level: if two
        concurrent transactions, that executed on different servers,
        update the same row, then there is a conflict. The conflict
        resolution procedure states that the transaction that was
        ordered first commits on all servers, and the transaction
        ordered second aborts, and is therefore rolled back on the
        originating server and dropped by the other servers in the
        group. For example, if t1 and t2 execute concurrently at
        different sites, both changing the same row, and t2 is ordered
        before t1, then t2 wins the conflict and t1 is rolled back. This
        is in fact a distributed first commit wins rule. Note that if
        two transactions are bound to conflict more often than not, then
        it is a good practice to start them on the same server, where
        they have a chance to synchronize on the local lock manager
        instead of being rolled back as a result of certification.
  </p>
  <p>
   For applying and externalizing the certified transactions, Group
        Replication permits servers to deviate from the agreed order of
        the transactions if this does not break consistency and
        validity. Group Replication is an eventual consistency system,
        meaning that as soon as the incoming traffic slows down or
        stops, all group members have the same data content. While
        traffic is flowing, transactions can be externalized in a
        slightly different order, or externalized on some members before
        the others. For example, in multi-primary mode, a local
        transaction might be externalized immediately following
        certification, although a remote transaction that is earlier in
        the global order has not yet been applied. This is permitted
        when the certification process has established that there is no
        conflict between the transactions. In single-primary mode, on
        the primary server, there is a small chance that concurrent,
        non-conflicting local transactions might be committed and
        externalized in a different order from the global order agreed
        by Group Replication. On the secondaries, which do not accept
        writes from clients, transactions are always committed and
        externalized in the agreed order.
  </p>
  <p>
   The following figure depicts the MySQL Group Replication
        protocol and by comparing it to MySQL Replication (or even MySQL
        semisynchronous replication) you can see some differences. Some
        underlying consensus and Paxos related messages are missing from
        this picture for the sake of clarity.
  </p>
  <div class="figure">
   <a name="idm46045134540320">
   </a>
   <p class="title">
    <b>
     Figure 20.3 MySQL Group Replication Protocol
    </b>
   </p>
   <div class="figure-contents">
    <div class="mediaobject">
     <img alt="A transaction received by Source 1 is executed. Source 1 then sends a message to the replication group, consisting of itself, Source 2, and Source 3. When all three members have reached consensus, they certify the transaction. Source 1 then writes the transaction to its binary log, commits it, and sends a response to the client application. Sources 2 and 3 write the transaction to their relay logs, then apply it, write it to the binary log, and commit it." src="images/gr-replication-diagram.png" style="width: 100%; max-width: 725px;"/>
    </div>
   </div>
  </div>
  <br class="figure-break"/>
 </div>
 <br/>
</div>
