<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="replication-upgrade">
      </a>
      19.5.3 Upgrading or Downgrading a Replication Topology
     </h3>
    </div>
   </div>
  </div>
  <p>
   When you upgrade servers that participate in a replication
      topology, you need to take into account each server's role in the
      topology and look out for issues specific to replication. For
      general information and instructions for upgrading a MySQL Server
      instance, see
   <a class="xref" href="upgrading.html" title="Chapter 3 Upgrading MySQL">
    Chapter 3,
    <i>
     Upgrading MySQL
    </i>
   </a>
   .
  </p>
  <p>
   As explained in
   <a class="xref" href="replication-compatibility.html" title="19.5.2 Replication Compatibility Between MySQL Versions">
    Section 19.5.2, “Replication Compatibility Between MySQL Versions”
   </a>
   , MySQL
      supports replication from an older source to a newer replica for
      version combinations where we support upgrades from the source
      version to the replica version as described at
   <a class="xref" href="mysql-releases.html" title="1.3 MySQL Releases: Innovation and LTS">
    Section 1.3, “MySQL Releases: Innovation and LTS”
   </a>
   and
   <a class="xref" href="upgrade-paths.html" title="3.2 Upgrade Paths">
    Section 3.2, “Upgrade Paths”
   </a>
   , but does not support replication
      from a source running a later release to a replica running an
      earlier release. A replica at an earlier release might not have
      the required capability to process transactions that can be
      handled by the source at a later release. You must therefore
      upgrade all of the replicas in a replication topology to the
      target MySQL Server release, before you upgrade the source server
      to the target release. In this way you will never be in the
      situation where a replica still at the earlier release is
      attempting to handle transactions from a source at the later
      release.
  </p>
  <p>
   In a replication topology where there are multiple sources
      (multi-source replication), the use of more than two MySQL Server
      versions is not supported, regardless of the number of source or
      replica MySQL servers. For example, you cannot use MySQL X.Y.1,
      MySQL X.Y.2, and MySQL X.Y.3 concurrently in such a setup,
      although you could use any two of these releases together.
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="idm46045134724336">
       </a>
       Pre-Check Servers before Upgrade
      </h4>
     </div>
    </div>
   </div>
   <p>
    It is possible to encounter replication difficulties when
        replicating from a source at an earlier release that has not yet
        been upgraded, to a replica at a later release that has been
        upgraded. This can happen if the source uses statements or
        relies on behavior that is no longer supported in the later
        release installed on the replica. You can use the MySQL Shell
        upgrade checker utility
    <code class="literal">
     util.checkForServerUpgrade()
    </code>
    to check MySQL
        8.0 server instances for upgrade to a MySQL 8.4 release. This
        utility identifies configuration and stored data that is known
        to potentially cause upgrade problems, including features and
        behaviors that are no longer available in the later release. See
    <a class="ulink" href="/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html" target="_top">
     Upgrade Checker Utility
    </a>
    for information
        on the upgrade checker utility.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="idm46045134720848">
       </a>
       Standard Upgrade Procedure
      </h4>
     </div>
    </div>
   </div>
   <p>
    To upgrade a replication topology, follow the instructions in
    <a class="xref" href="upgrading.html" title="Chapter 3 Upgrading MySQL">
     Chapter 3,
     <i>
      Upgrading MySQL
     </i>
    </a>
    for each individual MySQL Server
        instance, using this overall procedure:
   </p>
   <div class="orderedlist">
    <ol class="orderedlist" type="1">
     <li class="listitem">
      <p>
       Upgrade the replicas first. On each replica instance:
      </p>
      <div class="itemizedlist">
       <ul class="itemizedlist" style="list-style-type: disc; ">
        <li class="listitem">
         <p>
          Carry out the preliminary checks and steps described in
          <a class="xref" href="upgrade-prerequisites.html" title="3.6 Preparing Your Installation for Upgrade">
           Section 3.6, “Preparing Your Installation for Upgrade”
          </a>
          .
         </p>
        </li>
        <li class="listitem">
         <p>
          Shut down MySQL Server.
         </p>
        </li>
        <li class="listitem">
         <p>
          Upgrade the MySQL Server binaries or packages.
         </p>
        </li>
        <li class="listitem">
         <p>
          Restart MySQL Server.
         </p>
        </li>
        <li class="listitem">
         <p>
          MySQL Server performs the entire MySQL upgrade procedure
                automatically, disabling binary logging during the
                upgrade.
         </p>
        </li>
        <li class="listitem">
         <p>
          Restart replication using a
          <a class="link" href="start-replica.html" title="15.4.2.4 START REPLICA Statement">
           <code class="literal">
            START
                REPLICA
           </code>
          </a>
          .
         </p>
        </li>
       </ul>
      </div>
     </li>
     <li class="listitem">
      <p>
       If there are multiple layers of replicas
            (replicas-of-replicas) start upgrading the replicas that are
            farthest away from the source, performing the upgrade in a
            bottom-up fashion.
      </p>
     </li>
     <li class="listitem">
      <p>
       When all replicas have upgraded and only the source remains,
            perform a switch-over to one of the replicas. In other
            words, stop client updates on the source, wait for at least
            one replica to apply all changes, reconfigure the
            replication topology so that replica becomes the source and
            that the source is left outside the replication topology.
            Upgrade the old source according to the procedure for a
            single server, and then reinsert it into the topology.
      </p>
     </li>
    </ol>
   </div>
   <p>
    If you need to downgrade the servers in a replication topology,
        the source must be downgraded before the replicas are
        downgraded. On the replicas, you must ensure that the binary log
        and relay log have been fully processed, and purge them before
        proceeding with the downgrade.
   </p>
   <h5>
    <a name="idm46045134706544">
    </a>
    Rolling Downgrade Procedure
   </h5>
   <div class="orderedlist">
    <ol class="orderedlist" type="1">
     <li class="listitem">
      <p>
       Stop the updates.
      </p>
     </li>
     <li class="listitem">
      <p>
       Wait for replicas to receive all updates. It is not
            necessary to wait for them to apply all changes. If they
            have not applied all changes, leave their applier running so
            they can process the received transactions in the
            background.
      </p>
     </li>
     <li class="listitem">
      <p>
       Downgrade the source server, following the instructions for
            single server downgrade.
      </p>
     </li>
     <li class="listitem">
      <p>
       Insert the downgraded source server in the topology again.
      </p>
     </li>
     <li class="listitem">
      <p>
       Allow updates again.
      </p>
     </li>
     <li class="listitem">
      <p>
       Wait until all replicas have applied all remaining
            transactions from the previous primary.
      </p>
     </li>
     <li class="listitem">
      <p>
       For each replica, take out the replica from the topology,
            wait for it to apply all its relay log, downgrade it
            following the instructions for a single server downgrade,
            and reinsert it back into the topology. If there are
            multiple levels of replicas (replicas-of-replicas) then
            downgrade top-down starting with the replicas nearest to the
            source server.
      </p>
     </li>
    </ol>
   </div>
  </div>
 </div>
 <br/>
</div>
