<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-performance-xcom-cache-reduce">
      </a>
      20.7.6.2 Reducing the cache size
     </h4>
    </div>
   </div>
  </div>
  <p>
   The minimum setting for the XCom message cache size in MySQL
        8.4 is 128 MB, which enables deployment on a host
        that has a restricted amount of available memory. Having a very
        low
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_message_cache_size">
    <code class="literal">
     group_replication_message_cache_size
    </code>
   </a>
   setting is not recommended if the host is on an unstable
        network, because a smaller message cache makes it harder for
        group members to reconnect after a transient loss of
        connectivity.
  </p>
  <p>
   If a reconnecting member cannot retrieve all the messages it
        needs from the XCom message cache, the member must leave the
        group and rejoin it, in order to retrieve the missing
        transactions from another member's binary log using distributed
        recovery. A member that has left a group makes three auto-rejoin
        attempts by default, so the process of rejoining the group can
        still take place without operator intervention. However,
        rejoining using distributed recovery is a significantly longer
        and more complex process than retrieving messages from an XCom
        message cache, so the member takes longer to become available
        and the performance of the group can be impacted. On a stable
        network, which minimizes the frequency and duration of transient
        losses of connectivity for members, the frequency of this
        occurrence should also be minimized, so the group might be able
        to tolerate a smaller XCom message cache size without a
        significant impact on its performance.
  </p>
  <p>
   If you are considering reducing the cache size limit, you can
        query the Performance Schema table
   <a class="link" href="performance-schema-memory-summary-tables.html" title="29.12.20.10 Memory Summary Tables">
    <code class="literal">
     memory_summary_global_by_event_name
    </code>
   </a>
   using the following statement:
  </p>
  <div class="copytoclipboard-wrapper">
   <pre class="programlisting language-sql"><div class="docs-select-all right" id="sa6704907"><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 keyword">SELECT</span> <span class="token operator">*</span> <span class="token keyword">FROM</span> performance_schema<span class="token punctuation">.</span>memory_summary_global_by_event_name
  <span class="token keyword">WHERE</span> EVENT_NAME <span class="token operator">LIKE</span> <span class="token string">'memory/group_rpl/GCS_XCom::xcom_cache'</span><span class="token punctuation">;</span></code></pre>
  </div>
  <p>
   This returns memory usage statistics for the message cache,
        including the current number of cached entries and current size
        of the cache. If you reduce the cache size limit, XCom removes
        the oldest entries that have been decided and delivered until
        the current size is below the limit. XCom might temporarily
        exceed the cache size limit while this removal process is
        ongoing.
  </p>
 </div>
 <br/>
</div>
