<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-online-upgrade-methods">
      </a>
      20.8.3.3 Group Replication Online Upgrade Methods
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045131570096">
  </a>
  <p>
   Choose one of the following methods of upgrading a Group
        Replication group:
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-upgrading-rolling-in-group">
       </a>
       Rolling In-Group Upgrade
      </h5>
     </div>
    </div>
   </div>
   <p>
    This method is supported provided that servers running a newer
          version are not generating workload to the group while there
          are still servers with an older version in it. In other words
          servers with a newer version can join the group only as
          secondaries. In this method there is only ever one group, and
          each server instance is removed from the group, upgraded and
          then rejoined to the group.
   </p>
   <p>
    This method is well suited to single-primary groups. When the
          group is operating in single-primary mode, if you require the
          primary to remain the same throughout (except when it is being
          upgraded itself), it should be the last member to be upgraded.
          The primary cannot remain as the primary unless it is running
          the lowest MySQL Server version in the group. After the
          primary has been upgraded, you can use the
    <a class="link" href="group-replication-functions-for-new-primary.html#function_group-replication-set-as-primary">
     <code class="literal">
      group_replication_set_as_primary()
     </code>
    </a>
    function to reappoint it as the primary. If you do not mind
          which member is the primary, the members can be upgraded in
          any order. The group elects a new primary whenever necessary
          from among the members running the lowest MySQL Server
          version, following the election policies described in
    <a class="xref" href="group-replication-single-primary-mode.html" title="20.1.3.1 Single-Primary Mode">
     Section 20.1.3.1, “Single-Primary Mode”
    </a>
    .
   </p>
   <p>
    For groups operating in multi-primary mode, during a rolling
          in-group upgrade the number of primaries is decreased, causing
          a reduction in write availability. This is because if a member
          joins a group when it is running a higher MySQL Server version
          than the lowest version that the existing group members are
          running, it automatically remains in read-only mode
          (
    <a class="link" href="server-system-variables.html#sysvar_super_read_only">
     <code class="literal">
      super_read_only=ON
     </code>
    </a>
    ).
   </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 class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-upgrading-rolling-migration">
       </a>
       Rolling Migration Upgrade
      </h5>
     </div>
    </div>
   </div>
   <p>
    In this method you remove members from the group, upgrade them
          and then create a second group using the upgraded members. For
          groups operating in multi-primary mode, during this process
          the number of primaries is decreased, causing a reduction in
          write availability. This does not impact groups operating in
          single-primary mode.
   </p>
   <p>
    Because the group running the older version is online while
          you are upgrading the members, you need the group running the
          newer version to catch up with any transactions executed while
          the members were being upgraded. Therefore one of the servers
          in the new group is configured as a replica of a primary from
          the older group. This ensures that the new group catches up
          with the older group. Because this method relies on an
          asynchronous replication channel which is used to replicate
          data from one group to another, it is supported under the same
          assumptions and requirements of asynchronous source-replica
          replication, see
    <a class="xref" href="replication.html" title="Chapter 19 Replication">
     Chapter 19,
     <i>
      Replication
     </i>
    </a>
    . For groups
          operating in single-primary mode, the asynchronous replication
          connection to the old group must send data to the primary in
          the new group, for a multi-primary group the asynchronous
          replication channel can connect to any primary.
   </p>
   <p>
    The process is to:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       remove members from the original group running the older
              server version one by one, see
       <a class="xref" href="group-replication-upgrading-member.html" title="20.8.3.2 Upgrading a Group Replication Member">
        Section 20.8.3.2, “Upgrading a Group Replication Member”
       </a>
      </p>
     </li>
     <li class="listitem">
      <p>
       upgrade the server version running on the member, see
       <a class="xref" href="upgrading.html" title="Chapter 3 Upgrading MySQL">
        Chapter 3,
        <i>
         Upgrading MySQL
        </i>
       </a>
       . You can either follow an
              in-place or provision approach to upgrading.
      </p>
     </li>
     <li class="listitem">
      <p>
       create a new group with the upgraded members, see
       <a class="xref" href="group-replication.html" title="Chapter 20 Group Replication">
        Chapter 20,
        <i>
         Group Replication
        </i>
       </a>
       . In this case you need
              to configure a new group name on each member (because the
              old group is still running and using the old name),
              bootstrap an initial upgraded member, and then add the
              remaining upgraded members.
      </p>
     </li>
     <li class="listitem">
      <p>
       set up an asynchronous replication channel between the old
              group and the new group, see
       <a class="xref" href="replication-gtids-howto.html" title="19.1.3.4 Setting Up Replication Using GTIDs">
        Section 19.1.3.4, “Setting Up Replication Using GTIDs”
       </a>
       . Configure the
              older primary to function as the asynchronous replication
              source server and the new group member as a GTID-based
              replica.
      </p>
     </li>
    </ul>
   </div>
   <p>
    Before you can redirect your application to the new group, you
          must ensure that the new group has a suitable number of
          members, for example so that the group can handle the failure
          of a member. Issue
    <code class="literal">
     SELECT * FROM
          performance_schema.replication_group_members
    </code>
    and
          compare the initial group size and the new group size. Wait
          until all data from the old group is propagated to the new
          group and then drop the asynchronous replication connection
          and upgrade any missing members.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-upgrading-rolling-duplication">
       </a>
       Rolling Duplication Upgrade
      </h5>
     </div>
    </div>
   </div>
   <p>
    In this method you create a second group consisting of members
          which are running the newer version, and the data missing from
          the older group is replicated to the newer group. This assumes
          that you have enough servers to run both groups
          simultaneously. Due to the fact that during this process the
          number of primaries is
    <span class="emphasis">
     <em>
      not
     </em>
    </span>
    decreased, for
          groups operating in multi-primary mode there is no reduction
          in write availability. This makes rolling duplication upgrade
          well suited to groups operating in multi-primary mode. This
          does not impact groups operating in single-primary mode.
   </p>
   <p>
    Because the group running the older version is online while
          you are provisioning the members in the new group, you need
          the group running the newer version to catch up with any
          transactions executed while the members were being
          provisioned. Therefore one of the servers in the new group is
          configured as a replica of a primary from the older group.
          This ensures that the new group catches up with the older
          group. Because this method relies on an asynchronous
          replication channel which is used to replicate data from one
          group to another, it is supported under the same assumptions
          and requirements of asynchronous source-replica replication,
          see
    <a class="xref" href="replication.html" title="Chapter 19 Replication">
     Chapter 19,
     <i>
      Replication
     </i>
    </a>
    . For groups operating in
          single-primary mode, the asynchronous replication connection
          to the old group must send data to the primary in the new
          group, for a multi-primary group the asynchronous replication
          channel can connect to any primary.
   </p>
   <p>
    The process is to:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       deploy a suitable number of members so that the group
              running the newer version can handle failure of a member
      </p>
     </li>
     <li class="listitem">
      <p>
       take a backup of the existing data from a member of the
              group
      </p>
     </li>
     <li class="listitem">
      <p>
       use the backup from the older member to provision the
              members of the new group, see
       <a class="xref" href="group-replication-upgrade-with-mysqlbackup.html" title="20.8.3.4 Group Replication Upgrade with mysqlbackup">
        Section 20.8.3.4, “Group Replication Upgrade with mysqlbackup”
       </a>
       for one method.
      </p>
      <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
       <div class="admon-title">
        Note
       </div>
       <p>
        You must restore the backup to the same version of MySQL
                which the backup was taken from, and then perform an
                in-place upgrade. For instructions, see
        <a class="xref" href="upgrading.html" title="Chapter 3 Upgrading MySQL">
         Chapter 3,
         <i>
          Upgrading MySQL
         </i>
        </a>
        .
       </p>
      </div>
     </li>
     <li class="listitem">
      <p>
       create a new group with the upgraded members, see
       <a class="xref" href="group-replication.html" title="Chapter 20 Group Replication">
        Chapter 20,
        <i>
         Group Replication
        </i>
       </a>
       . In this case you need
              to configure a new group name on each member (because the
              old group is still running and using the old name),
              bootstrap an initial upgraded member, and then add the
              remaining upgraded members.
      </p>
     </li>
     <li class="listitem">
      <p>
       set up an asynchronous replication channel between the old
              group and the new group, see
       <a class="xref" href="replication-gtids-howto.html" title="19.1.3.4 Setting Up Replication Using GTIDs">
        Section 19.1.3.4, “Setting Up Replication Using GTIDs”
       </a>
       . Configure the
              older primary to function as the asynchronous replication
              source server and the new group member as a GTID-based
              replica.
      </p>
     </li>
    </ul>
   </div>
   <p>
    Once the ongoing data missing from the newer group is small
          enough to be quickly transferred, you must redirect write
          operations to the new group. Wait until all data from the old
          group is propagated to the new group and then drop the
          asynchronous replication connection.
   </p>
  </div>
 </div>
 <br/>
</div>
