<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-configuring-consistency-guarantees">
      </a>
      20.5.3.2 Configuring Transaction Consistency Guarantees
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045133339792">
  </a>
  <p>
   Although the
   <a class="xref" href="group-replication-understanding-consistency-guarantees.html#group-replication-synchronization-points" title="Transaction Synchronization Points">
    Transaction Synchronization Points
   </a>
   section explains that conceptually there are two synchronization
        points from which you can choose: on read or on write, these
        terms were a simplification and the terms used in Group
        Replication are:
   <span class="emphasis">
    <em>
     before
    </em>
   </span>
   and
   <span class="emphasis">
    <em>
     after
    </em>
   </span>
   transaction execution. The
        consistency level can have different effects on read-only and
        read/write transactions processed by the group as demonstrated
        in this section.
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-configuring-consistency-guarantees.html#group-replication-choose-consistency-level" title="How to Choose a Consistency Level">
       How to Choose a Consistency Level
      </a>
     </p>
    </li>
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-configuring-consistency-guarantees.html#group-replication-consistency-level-impacts" title="Impacts of Consistency Levels">
       Impacts of Consistency Levels
      </a>
     </p>
    </li>
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-configuring-consistency-guarantees.html#group-replication-consistency-level-impact-election" title="Impact of Consistency on Primary Election">
       Impact of Consistency on Primary Election
      </a>
     </p>
    </li>
    <li class="listitem">
     <p>
      <a class="xref" href="group-replication-configuring-consistency-guarantees.html#group-replication-nonblocking" title="Permitted Queries Under Consistency Rules">
       Permitted Queries Under Consistency Rules
      </a>
     </p>
    </li>
   </ul>
  </div>
  <p>
   The following list shows the possible consistency levels that
        you can configure in Group Replication using the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
    <code class="literal">
     group_replication_consistency
    </code>
   </a>
   variable, in order of increasing transaction consistency
        guarantee:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <code class="literal">
       EVENTUAL
      </code>
     </p>
     <p>
      Neither read-only nor read/write transactions wait for
            preceding transactions to be applied before executing. This
            was the behavior of Group Replication before the
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
       <code class="literal">
        group_replication_consistency
       </code>
      </a>
      variable was added. A read/write transaction does not wait
            for other members to apply a transaction. This means that a
            transaction could be externalized on one member before the
            others. This also means that in the event of a primary
            failover, the new primary can accept new read-only and
            read/write transactions before the previous primary
            transactions are all applied. Read-only transactions could
            result in outdated values, read/write transactions could
            result in a rollback due to conflicts.
     </p>
    </li>
    <li class="listitem">
     <p>
      <code class="literal">
       BEFORE_ON_PRIMARY_FAILOVER
      </code>
     </p>
     <p>
      New read-only or read/write transactions with a newly
            elected primary that is applying a backlog from the old
            primary are not applied until any backlog has been applied.
            This ensures that when a primary failover happens,
            intentionally or not, clients always see the latest value on
            the primary. This guarantees consistency, but means that
            clients must be able to handle the delay in the event that a
            backlog is being applied. Usually this delay should be
            minimal, but it does depend on the size of the backlog.
     </p>
    </li>
    <li class="listitem">
     <p>
      <code class="literal">
       BEFORE
      </code>
     </p>
     <p>
      A read/write transaction waits for all preceding
            transactions to complete before being applied. A read-only
            transaction waits for all preceding transactions to complete
            before being executed. This ensures that this transaction
            reads the latest value by only affecting the latency of the
            transaction. This reduces the overhead of synchronization on
            every read/write transaction, by ensuring synchronization is
            used only on read-only transactions. This consistency level
            also includes the consistency guarantees provided by
      <code class="literal">
       BEFORE_ON_PRIMARY_FAILOVER
      </code>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <code class="literal">
       AFTER
      </code>
     </p>
     <p>
      A read/write transaction waits until its changes have been
            applied to all of the other members. This value has no
            effect on read-only transactions. This mode ensures that
            when a transaction is committed on the local member, any
            subsequent transaction reads the written value or a more
            recent value on any group member. Use this mode with a group
            that is used for predominantly read-only operations to
            ensure that applied read/write transactions are applied
            everywhere once they commit. This could be used by your
            application to ensure that subsequent reads fetch the latest
            data which includes the latest writes. This reduces the
            overhead of synchronization on every read-only transaction,
            by ensuring synchronization is used only on read/write
            transactions. This consistency level also includes the
            consistency guarantees provided by
      <code class="literal">
       BEFORE_ON_PRIMARY_FAILOVER
      </code>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <code class="literal">
       BEFORE_AND_AFTER
      </code>
     </p>
     <p>
      A read/write transaction waits for 1) all preceding
            transactions to complete before being applied and 2) until
            its changes have been applied on other members. A read-only
            transaction waits for all preceding transactions to complete
            before execution takes place. This consistency level also
            includes the consistency guarantees provided by
      <code class="literal">
       BEFORE_ON_PRIMARY_FAILOVER
      </code>
      .
     </p>
    </li>
   </ul>
  </div>
  <p>
   The
   <code class="literal">
    BEFORE
   </code>
   and
   <code class="literal">
    BEFORE_AND_AFTER
   </code>
   consistency levels can be
        used on both read-only and read/write transactions. The
   <code class="literal">
    AFTER
   </code>
   consistency level has no impact on
        read-only transactions, because they do not generate changes.
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-choose-consistency-level">
       </a>
       How to Choose a Consistency Level
      </h5>
     </div>
    </div>
   </div>
   <a class="indexterm" name="idm46045133310032">
   </a>
   <p>
    The different consistency levels provide flexibility to both
          DBAs, who can use them to set up their infrastructure; and to
          developers who can use the consistency level that best suits
          their application's requirements. The following scenarios show
          how to choose a consistency guarantee level based on how you
          use your group:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 1
        </em>
       </span>
       : You want to balance reads
              without being concerned about stale reads, and group write
              operations are considerably fewer than group read
              operations. In this case, you should choose
       <code class="literal">
        AFTER
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 2
        </em>
       </span>
       : For a data set that
              applies many writes, you want to perform occasional reads
              without concerns about reading stale data. In this case,
              you should choose
       <code class="literal">
        BEFORE
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 3
        </em>
       </span>
       : You want specific
              transactions to read only up-to-date data from the group,
              so that whenever sensitive data such as credentials for a
              file is updated, reads always use the most recent value.
              In this case, you should choose
       <code class="literal">
        BEFORE
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 4
        </em>
       </span>
       : For a group that has
              predominantly read-only data, you want read/write
              transactions to be applied everywhere once they commit, so
              that subsequent reads are done on data that includes your
              latest writes and you do not incur the cost of
              synchronization for every read-only transaction, but only
              for read/write transactions. In this case, you should
              choose
       <code class="literal">
        AFTER
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 5
        </em>
       </span>
       : For a group that works
              predominantly with read-only data, you want read/write
              transactions to read up-to-date data from the group and to
              be applied everywhere once they commit, so that subsequent
              reads are performed on data that includes the latest write
              and you do not incur the cost of synchronization for every
              read-only transaction, but only for read/write
              transactions. In this case, you should choose
       <code class="literal">
        BEFORE_AND_AFTER
       </code>
       .
      </p>
     </li>
    </ul>
   </div>
   <p>
    You can choose the scope for which the consistency level is
          enforced by setting
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
     <code class="literal">
      group_replication_consistency
     </code>
    </a>
    with session or global scope. This is important because
          consistency levels can have a negative impact on group
          performance they apply globally.
   </p>
   <p>
    To enforce the consistency level for the current session, use
          session scope, like this:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting one-line language-sql"><div class="docs-select-all right" id="sa31323036"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token operator">&gt;</span> <span class="token keyword">SET</span> <span class="token variable">@@SESSION.group_replication_consistency</span><span class="token operator">=</span> <span class="token string">'BEFORE'</span><span class="token punctuation">;</span></code></pre>
   </div>
   <p>
    To enforce the consistency level for all sessions, use global
          scope, as shown here:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting one-line language-sql"><div class="docs-select-all right" id="sa97900485"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token operator">&gt;</span> <span class="token keyword">SET</span> <span class="token variable">@@GLOBAL.group_replication_consistency</span><span class="token operator">=</span> <span class="token string">'BEFORE'</span><span class="token punctuation">;</span></code></pre>
   </div>
   <p>
    The possibility of setting the consistency level on specific
          sessions enables you to take advantage of scenarios such as
          those listed here:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 6
        </em>
       </span>
       : A given system handles
              several instructions that do not require a strong
              consistency level, but one kind of instruction does
              require strong consistency: managing access permissions to
              documents;. In this scenario, the system changes access
              permissions and it wants to be sure that all clients see
              the correct permission. You only need to
       <code class="literal">
        SET
              @@SESSION.group_replication_consistency=
              ‘AFTER’
       </code>
       , on those instructions and leave the
              other instructions to run with
       <code class="literal">
        EVENTUAL
       </code>
       set at the global scope.
      </p>
     </li>
     <li class="listitem">
      <p>
       <span class="emphasis">
        <em>
         Scenario 7
        </em>
       </span>
       : On the same system as
              described in Scenario 6, a command that performs analytics
              needs to be executed daily, using the most up-to-date
              data. To achieve this, you need only run the SQL statement
       <code class="literal">
        SET @@SESSION.group_replication_consistency=
              ‘BEFORE’
       </code>
       prior to executing the command.
      </p>
     </li>
    </ul>
   </div>
   <p>
    In sum, you do not need to run all transactions with the same
          specific consistency level, especially if only some
          transactions actually require it.
   </p>
   <p>
    You should be aware that all read/write transactions are
          always ordered in Group Replication, so even when you set the
          consistency level to
    <code class="literal">
     AFTER
    </code>
    for the current
          session, this transaction waits until its changes are applied
          on all members, which means waiting for this and all preceding
          transactions that could be in the secondaries' queues. In
          other words, the consistency level
    <code class="literal">
     AFTER
    </code>
    waits for everything up to and including this transaction.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-consistency-level-impacts">
       </a>
       Impacts of Consistency Levels
      </h5>
     </div>
    </div>
   </div>
   <a class="indexterm" name="idm46045133279712">
   </a>
   <p>
    Another way to classify the consistency levels is in terms of
          impact on the group, that is, the repercussions that the
          consistency levels have on the other members.
   </p>
   <p>
    The
    <code class="literal">
     BEFORE
    </code>
    consistency level, apart from
          being ordered on the transaction stream, only impacts on the
          local member. That is, it does not require coordination with
          the other members and does not have repercussions on their
          transactions. In other words,
    <code class="literal">
     BEFORE
    </code>
    only
          impacts the transactions on which it is used.
   </p>
   <p>
    The
    <code class="literal">
     AFTER
    </code>
    and
    <code class="literal">
     BEFORE_AND_AFTER
    </code>
    consistency levels do have
          side-effects on concurrent transactions executed on other
          members. These consistency levels make the other members
          transactions wait if transactions with the
    <code class="literal">
     EVENTUAL
    </code>
    consistency level start while a
          transaction with
    <code class="literal">
     AFTER
    </code>
    or
    <code class="literal">
     BEFORE_AND_AFTER
    </code>
    is executing. The other
          members wait until the
    <code class="literal">
     AFTER
    </code>
    transaction is
          committed on that member, even if the other member's
          transactions have the
    <code class="literal">
     EVENTUAL
    </code>
    consistency
          level. In other words,
    <code class="literal">
     AFTER
    </code>
    and
    <code class="literal">
     BEFORE_AND_AFTER
    </code>
    impact
    <span class="emphasis">
     <em>
      all
     </em>
    </span>
    <code class="literal">
     ONLINE
    </code>
    group
          members.
   </p>
   <p>
    To illustrate this further, imagine a group with 3 members,
          M1, M2 and M3. On member M1 a client issues:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting language-sql"><div class="docs-select-all right" id="sa98300938"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token operator">&gt;</span> <span class="token keyword">SET</span> <span class="token variable">@@SESSION.group_replication_consistency</span><span class="token operator">=</span> <span class="token keyword">AFTER</span><span class="token punctuation">;</span>
<span class="token operator">&gt;</span> <span class="token keyword">BEGIN</span><span class="token punctuation">;</span>
<span class="token operator">&gt;</span> <span class="token keyword">INSERT</span> <span class="token keyword">INTO</span> t1 <span class="token keyword">VALUES</span> <span class="token punctuation">(</span><span class="token number">1</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
<span class="token operator">&gt;</span> <span class="token keyword">COMMIT</span><span class="token punctuation">;</span></code></pre>
   </div>
   <p>
    Then, while the above transaction is being applied, on member
          M2 a client issues:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting one-line language-sql"><div class="docs-select-all right" id="sa8402671"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token operator">&gt;</span> <span class="token keyword">SET</span> <span class="token keyword">SESSION</span> group_replication_consistency<span class="token operator">=</span> EVENTUAL<span class="token punctuation">;</span></code></pre>
   </div>
   <p>
    In this situation, even though the second transaction's
          consistency level is
    <code class="literal">
     EVENTUAL
    </code>
    , because it
          starts executing while the first transaction is already in the
          commit phase on M2, the second transaction has to wait for the
          first transaction to finish the commit and only then can it
          execute.
   </p>
   <p>
    You can only use the consistency levels
    <code class="literal">
     BEFORE
    </code>
    ,
    <code class="literal">
     AFTER
    </code>
    and
    <code class="literal">
     BEFORE_AND_AFTER
    </code>
    on
    <code class="literal">
     ONLINE
    </code>
    members, attempting to use them on
          members in other states causes a session error.
   </p>
   <p>
    Transactions whose consistency level is not
    <code class="literal">
     EVENTUAL
    </code>
    hold execution until a timeout,
          configured by
    <a class="link" href="server-system-variables.html#sysvar_wait_timeout">
     <code class="literal">
      wait_timeout
     </code>
    </a>
    value is reached, which defaults to 8 hours. If the timeout is
          reached an
    <a class="ulink" href="/doc/mysql-errors/8.4/en/server-error-reference.html#error_er_gr_hold_wait_timeout" target="_top">
     <code class="literal">
      ER_GR_HOLD_WAIT_TIMEOUT
     </code>
    </a>
    error
          is thrown.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-consistency-level-impact-election">
       </a>
       Impact of Consistency on Primary Election
      </h5>
     </div>
    </div>
   </div>
   <a class="indexterm" name="idm46045133254064">
   </a>
   <p>
    This section describes how a group's consistency level impacts
          on a single-primary group that has elected a new primary. Such
          a group automatically detects failures and adjusts the view of
          the members that are active, in other words the membership
          configuration. Furthermore, if a group is deployed in
          single-primary mode, whenever the group's membership changes
          there is a check performed to detect if there is still a
          primary member in the group. If there is none, a new one is
          selected from the list of secondary members. Typically, this
          is known as the secondary promotion.
   </p>
   <p>
    Given the fact that the system detects failures and
          reconfigures itself automatically, the user may also expect
          that once the promotion takes place, the new primary is in the
          exact state, data-wise, as that of the old one. In other
          words, the user may expect that there is no backlog of
          replicated transactions to be applied on the new primary once
          he is able to read from and write to it. In practical terms,
          the user may expect that once his application fails-over to
          the new primary, there would be no chance, even if
          temporarily, to read old data or write into old data records.
   </p>
   <p>
    When flow control is activated and properly tuned on a group,
          there is only a small chance of transiently reading stale data
          from a newly elected primary immediately after the promotion,
          as there should not be a backlog, or if there is one it should
          be small. Moreover, you might have a proxy or middleware
          layers that govern application accesses to the primary after a
          promotion and enforce the consistency criteria at that level.
          You can specify the behavior of the new primary once it is
          promoted using the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
     <code class="literal">
      group_replication_consistency
     </code>
    </a>
    variable, which controls whether a newly elected primary
          blocks both reads and writes until after the backlog is fully
          applied. If the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
     <code class="literal">
      group_replication_consistency
     </code>
    </a>
    variable was set to
    <code class="literal">
     BEFORE_ON_PRIMARY_FAILOVER
    </code>
    on a newly
          elected primary which has backlog to apply, and transactions
          are issued against the new primary while it is still applying
          the backlog, incoming transactions are blocked until the
          backlog is fully applied. This prevents the following
          anomalies:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       No stale reads for read-only and read/write transactions.
              This prevents stale reads from being externalized to the
              application by the new primary.
      </p>
     </li>
     <li class="listitem">
      <p>
       No spurious rollbacks for read/write transactions, due to
              write-write conflicts with replicated read/write
              transactions still in the backlog waiting to be applied.
      </p>
     </li>
     <li class="listitem">
      <p>
       No read skew on read/write transactions, such as this one:
      </p>
      <div class="copytoclipboard-wrapper">
       <pre class="programlisting language-sql"><div class="docs-select-all right" id="sa51560980"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token operator">&gt;</span> <span class="token keyword">BEGIN</span><span class="token punctuation">;</span>
<span class="token operator">&gt;</span> <span class="token keyword">SELECT</span> x <span class="token keyword">FROM</span> t1<span class="token punctuation">;</span> <span class="token comment" spellcheck="true">-- x=1 because x=2 is in the backlog;</span>
<span class="token operator">&gt;</span> <span class="token keyword">INSERT</span> x <span class="token keyword">INTO</span> t2<span class="token punctuation">;</span>
<span class="token operator">&gt;</span> <span class="token keyword">COMMIT</span><span class="token punctuation">;</span></code></pre>
      </div>
      <p>
       This query should not cause a conflict but writes outdated
              values.
      </p>
     </li>
    </ul>
   </div>
   <p>
    To summarize, when
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_consistency">
     <code class="literal">
      group_replication_consistency
     </code>
    </a>
    is set to
    <code class="literal">
     BEFORE_ON_PRIMARY_FAILOVER
    </code>
    you
          are choosing to prioritize consistency over availability,
          because reads and writes are held whenever a new primary is
          elected. This is the trade-off you have to consider when
          configuring your group. It should also be remembered that if
          flow control is working correctly, backlog should be minimal.
          Note that the higher consistency levels
    <code class="literal">
     BEFORE
    </code>
    ,
    <code class="literal">
     AFTER
    </code>
    , and
    <code class="literal">
     BEFORE_AND_AFTER
    </code>
    also include the
          consistency guarantees provided by
    <code class="literal">
     BEFORE_ON_PRIMARY_FAILOVER
    </code>
    .
   </p>
   <p>
    To guarantee that the group provides the same consistency
          level regardless of which member is promoted to primary, all
          members of the group should have
    <code class="literal">
     BEFORE_ON_PRIMARY_FAILOVER
    </code>
    (or a higher
          consistency level) persisted to their configuration. For
          example, on each member issue:
   </p>
   <div class="copytoclipboard-wrapper">
    <pre class="programlisting one-line language-sql"><div class="docs-select-all right" id="sa68501941"><div class="copy-help left">Press ⌘+C to copy</div> <div class="right"><button class="clipboard-btn" title="Copy to Clipboard"><span class="icon-clipboard"></span></button></div></div><code class="language-sql"><span class="token operator">&gt;</span> <span class="token keyword">SET</span> <span class="token keyword">PERSIST</span> group_replication_consistency<span class="token operator">=</span><span class="token string">'BEFORE_ON_PRIMARY_FAILOVER'</span><span class="token punctuation">;</span></code></pre>
   </div>
   <p>
    This ensures that the members all behave in the same way, and
          that the configuration is persisted after a restart of the
          member.
   </p>
   <p>
    A transaction cannot be on-hold forever, and if the time held
          exceeds
    <a class="link" href="server-system-variables.html#sysvar_wait_timeout">
     <code class="literal">
      wait_timeout
     </code>
    </a>
    it
          returns an
    <span class="errortext">
     ER_GR_HOLD_WAIT_TIMEOUT
    </span>
    error.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h5 class="title">
       <a name="group-replication-nonblocking">
       </a>
       Permitted Queries Under Consistency Rules
      </h5>
     </div>
    </div>
   </div>
   <p>
    Although all writes are held when using
    <code class="literal">
     BEFORE_ON_PRIMARY_FAILOVER
    </code>
    consistency
          level, not all reads are blocked to ensure that you can still
          inspect the server while it is applying backlog after a
          promotion took place. This is useful for debugging,
          monitoring, observability and troubleshooting. Some queries
          that do not modify data are allowed, such as the following:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <a class="link" href="show.html" title="15.7.7 SHOW Statements">
        <code class="literal">
         SHOW
        </code>
       </a>
       statements: These are
              restricted to those that do not depend on data, only on
              status and configuration.
      </p>
      <p>
       The
       <a class="link" href="show.html" title="15.7.7 SHOW Statements">
        <code class="literal">
         SHOW
        </code>
       </a>
       statements that
              are allowed are
       <code class="literal">
        SHOW VARIABLES
       </code>
       ,
       <code class="literal">
        SHOW PROCESSLIST
       </code>
       ,
       <code class="literal">
        SHOW
              STATUS
       </code>
       ,
       <code class="literal">
        SHOW ENGINE INNODB
              LOGS
       </code>
       ,
       <code class="literal">
        SHOW ENGINE INNODB
              STATUS
       </code>
       ,
       <code class="literal">
        SHOW ENGINE INNODB
              MUTEX
       </code>
       ,
       <code class="literal">
        SHOW BINARY LOG
              STATUS
       </code>
       ,
       <code class="literal">
        SHOW REPLICA STATUS
       </code>
       ,
       <code class="literal">
        SHOW CHARACTER SET
       </code>
       ,
       <code class="literal">
        SHOW
              COLLATION
       </code>
       ,
       <code class="literal">
        SHOW BINARY LOGS
       </code>
       ,
       <code class="literal">
        SHOW OPEN TABLES
       </code>
       ,
       <code class="literal">
        SHOW
              REPLICAS
       </code>
       ,
       <code class="literal">
        SHOW BINLOG EVENTS
       </code>
       ,
       <code class="literal">
        SHOW WARNINGS
       </code>
       ,
       <code class="literal">
        SHOW
              ERRORS
       </code>
       ,
       <code class="literal">
        SHOW ENGINES
       </code>
       ,
       <code class="literal">
        SHOW PRIVILEGES
       </code>
       ,
       <code class="literal">
        SHOW
              PROCEDURE STATUS
       </code>
       ,
       <code class="literal">
        SHOW FUNCTION
              STATUS
       </code>
       ,
       <code class="literal">
        SHOW PLUGINS
       </code>
       ,
       <code class="literal">
        SHOW EVENTS
       </code>
       ,
       <code class="literal">
        SHOW
              PROFILE
       </code>
       ,
       <code class="literal">
        SHOW PROFILES
       </code>
       , and
       <code class="literal">
        SHOW RELAYLOG EVENTS
       </code>
       .
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="set.html" title="13.3.6 The SET Type">
        <code class="literal">
         SET
        </code>
       </a>
       statements
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="do.html" title="15.2.3 DO Statement">
        <code class="literal">
         DO
        </code>
       </a>
       statements that do not
              use tables or loadable functions
      </p>
     </li>
     <li class="listitem">
      <p>
       <code class="literal">
        EMPTY
       </code>
       statements
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="use.html" title="15.8.4 USE Statement">
        <code class="literal">
         USE
        </code>
       </a>
       statements
      </p>
     </li>
     <li class="listitem">
      <p>
       Using
       <a class="link" href="select.html" title="15.2.13 SELECT Statement">
        <code class="literal">
         SELECT
        </code>
       </a>
       statements
              against the
       <code class="literal">
        performance_schema
       </code>
       and
       <code class="literal">
        sys
       </code>
       databases
      </p>
     </li>
     <li class="listitem">
      <p>
       Using
       <a class="link" href="select.html" title="15.2.13 SELECT Statement">
        <code class="literal">
         SELECT
        </code>
       </a>
       statements
              against the
       <code class="literal">
        PROCESSLIST
       </code>
       table from the
       <code class="literal">
        infoschema
       </code>
       database
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="select.html" title="15.2.13 SELECT Statement">
        <code class="literal">
         SELECT
        </code>
       </a>
       statements that do
              not use tables or loadable functions
      </p>
     </li>
     <li class="listitem">
      <p>
       <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>
       statements
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="shutdown.html" title="15.7.8.9 SHUTDOWN Statement">
        <code class="literal">
         SHUTDOWN
        </code>
       </a>
       statements
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="reset-persist.html" title="15.7.8.7 RESET PERSIST Statement">
        <code class="literal">
         RESET PERSIST
        </code>
       </a>
       statements
      </p>
     </li>
    </ul>
   </div>
  </div>
 </div>
 <br/>
</div>
