<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="group-replication-message-compression">
      </a>
      20.7.4 Message Compression
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045132157984">
  </a>
  <p>
   For messages sent between online group members, Group Replication
      enables message compression by default. Whether a specific message
      is compressed depends on the threshold that you configure using
      the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
    <code class="literal">
     group_replication_compression_threshold
    </code>
   </a>
   system variable. Messages that have a payload larger than the
      specified number of bytes are compressed.
  </p>
  <p>
   The default compression threshold is 1000000 bytes. You could use
      the following statements to increase the compression threshold to
      2MB, for example:
  </p>
  <div class="copytoclipboard-wrapper">
   <pre class="programlisting language-sql"><div class="docs-select-all right" id="sa7024708"><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">STOP</span> <span class="token keyword">GROUP_REPLICATION</span><span class="token punctuation">;</span>
<span class="token keyword">SET</span> <span class="token keyword">GLOBAL</span> group_replication_compression_threshold <span class="token operator">=</span> <span class="token number">2097152</span><span class="token punctuation">;</span>
<span class="token keyword">START</span> <span class="token keyword">GROUP_REPLICATION</span><span class="token punctuation">;</span></code></pre>
  </div>
  <p>
   If you set
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
    <code class="literal">
     group_replication_compression_threshold
    </code>
   </a>
   to zero, message compression is disabled.
  </p>
  <p>
   Group Replication uses the LZ4 compression algorithm to compress
      messages sent in the group. Note that the maximum supported input
      size for the LZ4 compression algorithm is 2113929216 bytes. This
      limit is lower than the maximum possible value for the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
    <code class="literal">
     group_replication_compression_threshold
    </code>
   </a>
   system variable, which is matched to the maximum message size
      accepted by XCom. The LZ4 maximum input size is therefore a
      practical limit for message compression, and transactions above
      this size cannot be committed when message compression is enabled.
      With the LZ4 compression algorithm, do not set a value greater
      than 2113929216 bytes for
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
    <code class="literal">
     group_replication_compression_threshold
    </code>
   </a>
   .
  </p>
  <p>
   The value of
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
    <code class="literal">
     group_replication_compression_threshold
    </code>
   </a>
   is not required by Group Replication to be the same on all group
      members. However, it is advisable to set the same value on all
      group members in order to avoid unnecessary rollback of
      transactions, failure of message delivery, or failure of message
      recovery.
  </p>
  <p>
   You can also configure compression for messages sent for
      distributed recovery by the method of state transfer from a
      donor's binary log. Compression for these messages, which are sent
      from a donor already in the group to a joining member, is
      controlled separately using the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_compression_algorithms">
    <code class="literal">
     group_replication_recovery_compression_algorithms
    </code>
   </a>
   and
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_zstd_compression_level">
    <code class="literal">
     group_replication_recovery_zstd_compression_level
    </code>
   </a>
   system variables. For more information, see
   <a class="xref" href="connection-compression-control.html" title="6.2.8 Connection Compression Control">
    Section 6.2.8, “Connection Compression Control”
   </a>
   .
  </p>
  <p>
   Binary log transaction compression, enabled by the
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_transaction_compression">
    <code class="literal">
     binlog_transaction_compression
    </code>
   </a>
   system variable, can also be used to save bandwidth. The
      transaction payloads remain compressed when they are transferred
      between group members. If you use binary log transaction
      compression in combination with Group Replication's message
      compression, message compression has less opportunity to act on
      the data, but can still compress headers and those events and
      transaction payloads that are uncompressed. For more information
      on binary log transaction compression, see
   <a class="xref" href="binary-log-transaction-compression.html" title="7.4.4.5 Binary Log Transaction Compression">
    Section 7.4.4.5, “Binary Log Transaction Compression”
   </a>
   .
  </p>
  <p>
   Compression for messages sent in the group happens at the group
      communication engine level, before the data is handed over to the
      group communication thread, so it takes place within the context
      of the
   <code class="literal">
    mysql
   </code>
   user session thread. If the
      message payload size exceeds the threshold set by
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_compression_threshold">
    <code class="literal">
     group_replication_compression_threshold
    </code>
   </a>
   ,
      the transaction payload is compressed before being sent out to the
      group, and decompressed when it is received. Upon receiving a
      message, the member checks the message envelope to verify whether
      it is compressed or not. If needed, then the member decompresses
      the transaction, before delivering it to the upper layer. This
      process is shown in the following figure.
  </p>
  <div class="figure">
   <a name="idm46045132135168">
   </a>
   <p class="title">
    <b>
     Figure 20.13 Compression Support
    </b>
   </p>
   <div class="figure-contents">
    <div class="mediaobject">
     <img alt="The MySQL Group Replication plugin architecture is shown as described in an earlier topic, with the five layers of the plugin positioned between the MySQL server and the replication group. Compression and decompression are handled by the Group Communication System API, which is the fourth layer of the Group Replication plugin. The group communication engine (the fifth layer of the plugin) and the group members use the compressed transactions with the smaller data size. The MySQL Server core and the three higher layers of the Group Replication plugin (the APIs, the capture, applier, and recovery components, and the replication protocol module) use the original transactions with the larger data size." src="images/gr-compress-decompress.png" style="width: 100%; max-width: 588px;"/>
    </div>
   </div>
  </div>
  <br class="figure-break"/>
  <p>
   When network bandwidth is a bottleneck, message compression can
      provide up to 30-40% throughput improvement at the group
      communication level. This is especially important within the
      context of large groups of servers under load. The TCP
      peer-to-peer nature of the interconnections between
   <span class="emphasis">
    <em>
     N
    </em>
   </span>
   participants in the group makes the sender
      send the same amount of data
   <span class="emphasis">
    <em>
     N
    </em>
   </span>
   times.
      Furthermore, binary logs are likely to exhibit a high compression
      ratio. This makes compression a compelling feature for Group
      Replication workloads that contain large transactions.
  </p>
 </div>
 <br/>
</div>
