<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-upgrading-member">
      </a>
      20.8.3.2 Upgrading a Group Replication Member
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045131600000">
  </a>
  <p>
   This section explains the steps required for upgrading a member
        of a group. This procedure is part of the methods described at
   <a class="xref" href="group-replication-online-upgrade-methods.html" title="20.8.3.3 Group Replication Online Upgrade Methods">
    Section 20.8.3.3, “Group Replication Online Upgrade Methods”
   </a>
   . The
        process of upgrading a member of a group is common to all
        methods and is explained first. The way which you join upgraded
        members can depend on which method you are following, and other
        factors such as whether the group is operating in single-primary
        or multi-primary mode. How you upgrade the server instance,
        using either the in-place or provision approach, does not impact
        on the methods described here.
  </p>
  <p>
   The process of upgrading a member consists of removing it from
        the group, following your chosen method of upgrading the member,
        and then rejoining the upgraded member to a group. The
        recommended order of upgrading members in a single-primary group
        is to upgrade all secondaries, and then upgrade the primary
        last. If the primary is upgraded before a secondary, a new
        primary using the older MySQL version is chosen, but there is no
        need for this step.
  </p>
  <p>
   To upgrade a member of a group:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      Connect a client to the group member and issue
      <a class="link" href="stop-group-replication.html" title="15.4.3.2 STOP GROUP_REPLICATION Statement">
       <code class="literal">
        STOP GROUP_REPLICATION
       </code>
      </a>
      .
            Before proceeding, ensure that the member's status is
      <code class="literal">
       OFFLINE
      </code>
      by monitoring the
      <a class="link" href="performance-schema-replication-group-members-table.html" title="29.12.11.16 The replication_group_members Table">
       <code class="literal">
        replication_group_members
       </code>
      </a>
      table.
     </p>
    </li>
    <li class="listitem">
     <p>
      Disable Group Replication from starting up automatically so
            that you can safely connect to the member after upgrading
            and configure it without it rejoining the group by setting
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_start_on_boot">
       <code class="literal">
        group_replication_start_on_boot=0
       </code>
      </a>
      .
     </p>
     <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
      <div class="admon-title">
       Important
      </div>
      <p>
       If an upgraded member has
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_start_on_boot">
        <code class="literal">
         group_replication_start_on_boot=1
        </code>
       </a>
       then it could
              rejoin the group before you can perform the MySQL upgrade
              procedure and could result in issues. For example, if the
              upgrade fails and the server restarts again, then a
              possibly broken server could try to join the group.
      </p>
     </div>
    </li>
    <li class="listitem">
     <p>
      Stop the member, for example using
      <a class="link" href="mysqladmin.html" title="6.5.2 mysqladmin — A MySQL Server Administration Program">
       <span class="command">
        <strong>
         mysqladmin
            shutdown
        </strong>
       </span>
      </a>
      or the
      <a class="link" href="shutdown.html" title="15.7.8.9 SHUTDOWN Statement">
       <code class="literal">
        SHUTDOWN
       </code>
      </a>
      statement. Any other
            members in the group continue running.
     </p>
    </li>
    <li class="listitem">
     <p>
      Upgrade the member, using the in-place or provisioning
            approach. See
      <a class="xref" href="upgrading.html" title="Chapter 3 Upgrading MySQL">
       Chapter 3,
       <i>
        Upgrading MySQL
       </i>
      </a>
      for details. When
            restarting the upgraded member, because
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_start_on_boot">
       <code class="literal">
        group_replication_start_on_boot
       </code>
      </a>
      is set to 0, Group
            Replication does not start on the instance, and therefore it
            does not rejoin the group.
     </p>
    </li>
    <li class="listitem">
     <p>
      Once the MySQL upgrade procedure has been performed on the
            member,
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_start_on_boot">
       <code class="literal">
        group_replication_start_on_boot
       </code>
      </a>
      must be set to 1 to ensure Group Replication starts
            correctly after restart. Restart the member.
     </p>
    </li>
    <li class="listitem">
     <p>
      Connect to the upgraded member and issue
      <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
       <code class="literal">
        START GROUP_REPLICATION
       </code>
      </a>
      . This
            rejoins the member to the group. The Group Replication
            metadata is in place on the upgraded server, therefore there
            is usually no need to reconfigure Group Replication. The
            server has to catch up with any transactions processed by
            the group while the server was offline. Once it has caught
            up with the group, it becomes an online member of the group.
     </p>
     <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
      <div class="admon-title">
       Note
      </div>
      <p>
       The longer it takes to upgrade a server, the more time
              that member is offline and therefore the more time it
              takes for the server to catch up when added back to the
              group.
      </p>
     </div>
    </li>
   </ul>
  </div>
  <p>
   When an upgraded member joins a group which has any member
        running an earlier MySQL Server version, the upgraded member
        joins with
   <a class="link" href="server-system-variables.html#sysvar_super_read_only">
    <code class="literal">
     super_read_only=on
    </code>
   </a>
   .
        This ensures that no writes are made to upgraded members until
        all members are running the newer version. In a multi-primary
        mode group, when the upgrade has been completed successfully and
        the group is ready to process transactions, members that are
        intended as writeable primaries must be set to read/write mode.
        When all members of a group have been upgraded to the same
        release, they all change back to read/write mode automatically.
  </p>
 </div>
 <br/>
</div>
