<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-features-max-allowed-packet">
      </a>
      19.5.1.20 Replication and max_allowed_packet
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045135361728">
  </a>
  <a class="indexterm" name="idm46045135360240">
  </a>
  <p>
   <a class="link" href="server-system-variables.html#sysvar_max_allowed_packet">
    <code class="literal">
     max_allowed_packet
    </code>
   </a>
   sets an
        upper limit on the size of any single message between the MySQL
        server and clients, including replicas. If you are replicating
        large column values (such as might be found in
   <a class="link" href="blob.html" title="13.3.4 The BLOB and TEXT Types">
    <code class="literal">
     TEXT
    </code>
   </a>
   or
   <a class="link" href="blob.html" title="13.3.4 The BLOB and TEXT Types">
    <code class="literal">
     BLOB
    </code>
   </a>
   columns) and
   <a class="link" href="server-system-variables.html#sysvar_max_allowed_packet">
    <code class="literal">
     max_allowed_packet
    </code>
   </a>
   is too small
        on the source, the source fails with an error, and the replica
        shuts down the replication I/O (receiver) thread. If
   <a class="link" href="server-system-variables.html#sysvar_max_allowed_packet">
    <code class="literal">
     max_allowed_packet
    </code>
   </a>
   is too small
        on the replica, this also causes the replica to stop the I/O
        thread.
  </p>
  <p>
   Row-based replication sends all columns and column values for
        updated rows from the source to the replica, including values of
        columns that were not actually changed by the update. This means
        that, when you are replicating large column values using
        row-based replication, you must take care to set
   <a class="link" href="server-system-variables.html#sysvar_max_allowed_packet">
    <code class="literal">
     max_allowed_packet
    </code>
   </a>
   large enough
        to accommodate the largest row in any table to be replicated,
        even if you are replicating updates only, or you are inserting
        only relatively small values.
  </p>
  <p>
   On a multi-threaded replica (with
   <a class="link" href="replication-options-replica.html#sysvar_replica_parallel_workers">
    <code class="literal">
     replica_parallel_workers &gt;
        0
    </code>
   </a>
   ), ensure that the system variable
   <a class="link" href="replication-options-replica.html#sysvar_replica_pending_jobs_size_max">
    <code class="literal">
     replica_pending_jobs_size_max
    </code>
   </a>
   is set to a value equal to or greater than the setting for the
   <a class="link" href="server-system-variables.html#sysvar_max_allowed_packet">
    <code class="literal">
     max_allowed_packet
    </code>
   </a>
   system
        variable on the source. The default setting for
   <code class="literal">
    replica_pending_jobs_size_max
   </code>
   , 128M, is twice
        the default setting for
   <code class="literal">
    max_allowed_packet
   </code>
   ,
        which is 64M.
   <code class="literal">
    max_allowed_packet
   </code>
   limits the
        packet size that the source can send, but the addition of an
        event header can produce a binary log event exceeding this size.
        Also, in row-based replication, a single event can be
        significantly larger than the
   <code class="literal">
    max_allowed_packet
   </code>
   size, because the value of
   <code class="literal">
    max_allowed_packet
   </code>
   only limits each column of
        the table.
  </p>
  <p>
   The replica actually accepts packets up to the limit set by its
   <a class="link" href="replication-options-replica.html#sysvar_replica_max_allowed_packet">
    <code class="literal">
     replica_max_allowed_packet
    </code>
   </a>
   setting, which default to the maximum setting of 1GB, to prevent
        a replication failure due to a large packet. However, the value
        of
   <a class="link" href="replication-options-replica.html#sysvar_replica_pending_jobs_size_max">
    <code class="literal">
     replica_pending_jobs_size_max
    </code>
   </a>
   controls the memory that is made available on the replica to
        hold incoming packets. The specified memory is shared among all
        the replica worker queues.
  </p>
  <p>
   The value of
   <a class="link" href="replication-options-replica.html#sysvar_replica_pending_jobs_size_max">
    <code class="literal">
     replica_pending_jobs_size_max
    </code>
   </a>
   is a soft limit, and if an unusually large event (consisting of
        one or multiple packets) exceeds this size, the transaction is
        held until all the replica workers have empty queues, and then
        processed. All subsequent transactions are held until the large
        transaction has been completed. So although unusual events
        larger than
   <a class="link" href="replication-options-replica.html#sysvar_replica_pending_jobs_size_max">
    <code class="literal">
     replica_pending_jobs_size_max
    </code>
   </a>
   can be processed, the delay to clear the queues of all the
        replica workers and the wait to queue subsequent transactions
        can cause lag on the replica and decreased concurrency of the
        replica workers.
   <a class="link" href="replication-options-replica.html#sysvar_replica_pending_jobs_size_max">
    <code class="literal">
     replica_pending_jobs_size_max
    </code>
   </a>
   should therefore be set high enough to accommodate most expected
        event sizes.
  </p>
 </div>
 <br/>
</div>
