<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h2 class="title">
      <a name="group-replication-background">
      </a>
      20.1 Group Replication Background
     </h2>
    </div>
   </div>
  </div>
  <div class="toc">
   <dl class="toc">
    <dt>
     <span class="section">
      <a href="group-replication-replication-technologies.html">
       20.1.1 Replication Technologies
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-use-cases.html">
       20.1.2 Group Replication Use Cases
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-deploying-in-multi-primary-or-single-primary-mode.html">
       20.1.3 Multi-Primary and Single-Primary Modes
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-details.html">
       20.1.4 Group Replication Services
      </a>
     </span>
    </dt>
    <dt>
     <span class="section">
      <a href="group-replication-plugin-architecture.html">
       20.1.5 Group Replication Plugin Architecture
      </a>
     </span>
    </dt>
   </dl>
  </div>
  <a class="indexterm" name="idm46045134588512">
  </a>
  <p>
   This section provides background information on MySQL Group
    Replication.
  </p>
  <p>
   The most common way to create a fault-tolerant system is to resort
    to making components redundant, in other words the component can be
    removed and the system should continue to operate as expected. This
    creates a set of challenges that raise complexity of such systems to
    a whole different level. Specifically, replicated databases have to
    deal with the fact that they require maintenance and administration
    of several servers instead of just one. Moreover, as servers are
    cooperating together to create the group several other classic
    distributed systems problems have to be dealt with, such as network
    partitioning or split brain scenarios.
  </p>
  <p>
   Therefore, the ultimate challenge is to fuse the logic of the
    database and data replication with the logic of having several
    servers coordinated in a consistent and simple way. In other words,
    to have multiple servers agreeing on the state of the system and the
    data on each and every change that the system goes through. This can
    be summarized as having servers reaching agreement on each database
    state transition, so that they all progress as one single database
    or alternatively that they eventually converge to the same state.
    Meaning that they need to operate as a (distributed) state machine.
  </p>
  <p>
   MySQL Group Replication provides distributed state machine
    replication with strong coordination between servers. Servers
    coordinate themselves automatically when they are part of the same
    group. The group can operate in a single-primary mode with automatic
    primary election, where only one server accepts updates at a time.
    Alternatively, for more advanced users the group can be deployed in
    multi-primary mode, where all servers can accept updates, even if
    they are issued concurrently. This power comes at the expense of
    applications having to work around the limitations imposed by such
    deployments.
  </p>
  <p>
   There is a built-in group membership service that keeps the view of
    the group consistent and available for all servers at any given
    point in time. Servers can leave and join the group and the view is
    updated accordingly. Sometimes servers can leave the group
    unexpectedly, in which case the failure detection mechanism detects
    this and notifies the group that the view has changed. This is all
    automatic.
  </p>
  <p>
   For a transaction to commit, the majority of the group have to agree
    on the order of a given transaction in the global sequence of
    transactions. Deciding to commit or abort a transaction is done by
    each server individually, but all servers make the same decision. If
    there is a network partition, resulting in a split where members are
    unable to reach agreement, then the system does not progress until
    this issue is resolved. Hence there is also a built-in, automatic,
    split-brain protection mechanism.
  </p>
  <p>
   All of this is powered by the provided Group Communication System
    (GCS) protocols. These provide a failure detection mechanism, a
    group membership service, and safe and completely ordered message
    delivery. All these properties are key to creating a system which
    ensures that data is consistently replicated across the group of
    servers. At the very core of this technology lies an implementation
    of the Paxos algorithm. It acts as the group communication engine.
  </p>
 </div>
 <br/>
</div>
