MySQL 9.1 Release Notes
max_allowed_packet 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
TEXT or
BLOB columns) and
max_allowed_packet is too small
on the source, the source fails with an error, and the replica
shuts down the replication I/O (receiver) thread. If
max_allowed_packet is too small
on the replica, this also causes the replica to stop the I/O
thread.
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
max_allowed_packet 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.
On a multi-threaded replica (with
replica_parallel_workers >
0), ensure that the system variable
replica_pending_jobs_size_max
is set to a value equal to or greater than the setting for the
max_allowed_packet system
variable on the source. The default setting for
replica_pending_jobs_size_max, 128M, is twice
the default setting for max_allowed_packet,
which is 64M. max_allowed_packet 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
max_allowed_packet size, because the value of
max_allowed_packet only limits each column of
the table.
The replica actually accepts packets up to the limit set by its
replica_max_allowed_packet
setting, which default to the maximum setting of 1GB, to prevent
a replication failure due to a large packet. However, the value
of
replica_pending_jobs_size_max
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.
The value of
replica_pending_jobs_size_max
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
replica_pending_jobs_size_max
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.
replica_pending_jobs_size_max
should therefore be set high enough to accommodate most expected
event sizes.