<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-multi-primary-mode">
      </a>
      20.1.3.2 Multi-Primary Mode
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045134440000">
  </a>
  <p>
   In multi-primary mode
        (
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_single_primary_mode">
    <code class="literal">
     group_replication_single_primary_mode=OFF
    </code>
   </a>
   )
        no member has a special role. Any member that is compatible with
        the other group members is set to read/write mode when joining
        the group, and can process write transactions, even if they are
        issued concurrently.
  </p>
  <p>
   If a member stops accepting write transactions, for example, in
        the event of an unexpected server exit, clients connected to it
        can be redirected, or failed over, to any other member that is
        in read/write mode. Group Replication does not handle
        client-side failover itself, so you need to arrange this using a
        middleware framework such as
   <a class="ulink" href="/doc/mysql-router/8.4/en/" target="_top">
    MySQL Router 8.4
   </a>
   , a
        proxy, a connector, or the application itself.
   <a class="xref" href="group-replication-multi-primary-mode.html#group-replication-multi-primary-diagram" title="Figure 20.5 Client Failover">
    Figure 20.5, “Client Failover”
   </a>
   shows
        how clients can reconnect to an alternative group member if a
        member leaves the group.
  </p>
  <div class="figure">
   <a name="group-replication-multi-primary-diagram">
   </a>
   <p class="title">
    <b>
     Figure 20.5 Client Failover
    </b>
   </p>
   <div class="figure-contents">
    <div class="mediaobject">
     <img alt="Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. All of the servers are primaries. Write clients are communicating with servers S1 and S2, and a read client is communicating with server S4. Server S1 then fails, breaking communication with its write client. This client reconnects to server S3." src="images/multi-primary.png" style="width: 100%; max-width: 899px;"/>
    </div>
   </div>
  </div>
  <br class="figure-break"/>
  <p>
   Group Replication is an eventual consistency system. This means
        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 on some members before
        the others, especially if some members have less write
        throughput than others, creating the possibility of stale reads.
        In multi-primary mode, slower members can also build up an
        excessive backlog of transactions to certify and apply, leading
        to a greater risk of conflicts and certification failure. To
        limit these issues, you can activate and tune Group
        Replication's flow control mechanism to minimize the difference
        between fast and slow members. For more information on flow
        control, see
   <a class="xref" href="group-replication-flow-control.html" title="20.7.2 Flow Control">
    Section 20.7.2, “Flow Control”
   </a>
   .
  </p>
  <p>
   If you want transaction consistency guaranteed for every
        transaction in the group, you can do this using the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
    <code class="literal">
     group_replication_consistency
    </code>
   </a>
   system variable. You can choose a setting that suits the
        workload of your group and your priorities for data reads and
        writes, taking into account the performance impact of the
        synchronization required to increase consistency. You can also
        set the system variable for individual sessions to protect
        particularly concurrency-sensitive transactions. For more
        information on transaction consistency, see
   <a class="xref" href="group-replication-consistency-guarantees.html" title="20.5.3 Transaction Consistency Guarantees">
    Section 20.5.3, “Transaction Consistency Guarantees”
   </a>
   .
  </p>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-multi-primary-checks">
       </a>
       20.1.3.2.1 Transaction Checks
      </h5>
     </div>
    </div>
   </div>
   <p>
    When a group is deployed in multi-primary mode, transactions
          are checked to ensure they are compatible with the mode. The
          following strict consistency checks are made when Group
          Replication is deployed in multi-primary mode:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       If a transaction is executed under the SERIALIZABLE
              isolation level, then its commit fails when synchronizing
              itself with the group.
      </p>
     </li>
     <li class="listitem">
      <p>
       If a transaction executes against a table that has foreign
              keys with cascading constraints, then its commit fails
              when synchronizing itself with the group.
      </p>
     </li>
    </ul>
   </div>
   <p>
    The checks are controlled by the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks">
     <code class="literal">
      group_replication_enforce_update_everywhere_checks
     </code>
    </a>
    system variable. In multi-primary mode, the system variable
          should normally be set to
    <code class="literal">
     ON
    </code>
    , but the
          checks can optionally be deactivated by setting the system
          variable to
    <code class="literal">
     OFF
    </code>
    . When deploying in
          single-primary mode, the system variable must be set to
    <code class="literal">
     OFF
    </code>
    .
   </p>
  </div>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-data-definition-statements">
       </a>
       20.1.3.2.2 Data Definition Statements
      </h5>
     </div>
    </div>
   </div>
   <a class="indexterm" name="idm46045134412416">
   </a>
   <p>
    In a Group Replication topology in multi-primary mode, care
          needs to be taken when executing data definition statements,
          also commonly known as data definition language (DDL).
   </p>
   <p>
    MySQL 8.4 supports atomic Data Definition
          Language (DDL) statements, where the complete DDL statement is
          either committed or rolled back as a single atomic
          transaction. DDL statements, atomic or otherwise, implicitly
          end any transaction that is active in the current session, as
          if you had done a
    <a class="link" href="commit.html" title="15.3.1 START TRANSACTION, COMMIT, and ROLLBACK Statements">
     <code class="literal">
      COMMIT
     </code>
    </a>
    before
          executing the statement. This means that DDL statements cannot
          be performed within another transaction, within transaction
          control statements such as
    <a class="link" href="commit.html" title="15.3.1 START TRANSACTION, COMMIT, and ROLLBACK Statements">
     <code class="literal">
      START TRANSACTION ...
          COMMIT
     </code>
    </a>
    , or combined with other statements within the
          same transaction.
   </p>
   <p>
    Group Replication is based on an optimistic replication
          paradigm, where statements are optimistically executed and
          rolled back later if necessary. Each server executes without
          securing group agreement first. Therefore, more care needs to
          be taken when replicating DDL statements in multi-primary
          mode. If you make schema changes (using DDL) and changes to
          the data that an object contains (using DML) for the same
          object, the changes need to be handled through the same server
          while the schema operation has not yet completed and
          replicated everywhere. Failure to do so can result in data
          inconsistency when operations are interrupted or only
          partially completed. If the group is deployed in
          single-primary mode this issue does not occur, because all
          changes are performed through the same server, the primary.
   </p>
   <p>
    For more information about atomic DDL support, see
    <a class="xref" href="atomic-ddl.html" title="15.1.1 Atomic Data Definition Statement Support">
     Section 15.1.1, “Atomic Data Definition Statement Support”
    </a>
    .
   </p>
  </div>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-multi-primary-compatibility">
       </a>
       20.1.3.2.3 Version Compatibility
      </h5>
     </div>
    </div>
   </div>
   <p>
    For optimal compatibility and performance, all members of a
          group should run the same version of MySQL Server and
          therefore of Group Replication. In multi-primary mode, this is
          more significant because all members would normally join the
          group in read/write mode. If a group includes members running
          more than one MySQL Server version, there is a potential for
          some members to be incompatible with others, because they
          support functions others do not, or lack functions others
          have. To guard against this, when a new member joins
          (including a former member that has been upgraded and
          restarted), the member carries out compatibility checks
          against the rest of the group.
   </p>
   <p>
    One result of these compatibility checks is particularly
          important in multi-primary mode. If a joining member is
          running a higher MySQL Server version than the lowest version
          that the existing group members are running, it joins the
          group but remains in read-only mode. (In a group that is
          running in single-primary mode, new members default to
          read-only in any case.) Members take into account the
          major.minor.release version of the MySQL software (and thus,
          of the Group Replication plugin) when checking their
          compatibility.
   </p>
   <p>
    In a group running in multi-primary mode with members that use
          different MySQL Server versions, Group Replication
          automatically manages their read/write and read-only status.
          If a member leaves the group, the members running the version
          that is now the lowest are automatically set to read/write
          mode. When you change a group that was running in
          single-primary mode to run in multi-primary mode, using the
          function
    <a class="link" href="group-replication-functions-for-mode.html#function_group-replication-switch-to-multi-primary-mode">
     <code class="literal">
      group_replication_switch_to_multi_primary_mode()
     </code>
    </a>
    ,
          Group Replication automatically sets members to the correct
          mode. Members are automatically placed in read-only mode if
          they are running a higher MySQL server version than the lowest
          version present in the group, and members running the lowest
          version are placed in read/write mode.
   </p>
   <p>
    For full information on version compatibility in a group and
          how this influences the behavior of a group during an upgrade
          process, see
    <a class="xref" href="group-replication-online-upgrade-combining-versions.html" title="20.8.1 Combining Different Member Versions in a Group">
     Section 20.8.1, “Combining Different Member Versions in a Group”
    </a>
    .
   </p>
  </div>
 </div>
 <br/>
</div>
