<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-compatibility-upgrade">
      </a>
      20.8.1.1 Member Versions During Upgrades
     </h4>
    </div>
   </div>
  </div>
  <p>
   During an online upgrade procedure, if the group is in
        single-primary mode, all the servers that are not currently
        offline for upgrading function as they did before. The group
        elects a new primary whenever necessary, 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>
   . Note
        that if you require the primary to remain the same throughout
        (except when it is being upgraded itself), you must first
        upgrade all of the secondaries to a version higher than or equal
        to the target primary member version, then upgrade the primary
        last. 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.
  </p>
  <p>
   If the group is in multi-primary mode, fewer online members are
        available to perform writes during the upgrade procedure,
        because upgraded members join in read-only mode after their
        upgrade. When all members have been upgraded to the same
        release, they all change back to read/write mode automatically.
  </p>
  <p>
   To deal with a problem situation, for example if you have to
        roll back an upgrade to a previous major version or add extra
        capacity to a group in an emergency, it is possible to allow a
        member to join an online group from a version that otherwise
        couldn't. The deprecated Group Replication system variable
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_allow_local_lower_version_join">
    <code class="literal">
     group_replication_allow_local_lower_version_join
    </code>
   </a>
   can be used in such situations to override the normal
        compatibility policies.
  </p>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    Setting
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_allow_local_lower_version_join">
     <code class="literal">
      group_replication_allow_local_lower_version_join
     </code>
    </a>
    to
    <code class="literal">
     ON
    </code>
    does
    <span class="emphasis">
     <em>
      not
     </em>
    </span>
    make
          the new member compatible with the group; doing this allows it
          to join the group without any safeguards against incompatible
          behaviors by the existing members. This must therefore only be
          used carefully in specific situations, and you must take
          additional precautions to avoid the new member failing due to
          normal group activity. See the description of this variable
          for more information.
   </p>
  </div>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    <code class="literal">
     group_replication_allow_local_lower_version_join
    </code>
    is deprecated and subject to removal in a future version of
          MySQL. Setting it generates a
    <a class="ulink" href="/doc/mysql-errors/8.4/en/server-error-reference.html#error_er_warn_deprecated_syntax_no_replacement" target="_top">
     <code class="literal">
      ER_WARN_DEPRECATED_SYNTAX_NO_REPLACEMENT
     </code>
    </a>
    warning.
   </p>
  </div>
 </div>
 <br/>
</div>
