Bug #55247 fragmentation layer for transferring over max_allowed_packet rows-event
Submitted: 14 Jul 2010 8:20 Modified: 14 Jul 2010 10:10
Reporter: Andrei Elkin Email Updates:
Status: In progress Impact on me:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.1+ OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Tags: replication event size

[14 Jul 2010 8:20] Andrei Elkin
Specifics of Rows_log_event format makes possible a Rows-event size be bigger
than any max_allowed_packet incl max(max_allowed_packet) which means such event can't be sent/received by master/slave.
An example of such Rows-log-event can be an Update_rows_log_event on a table with at least two attributes each size of 1GB.

An attempt to tackle this issue within Bug #49931 left a flaw in that
slave is made to read a packet size of over max_allowed_packet representing 
Rows-event. However that is not possible meaning that slave plays the client role
in client-server protocol and the protocol specifies the maximum size max_allowed_packet for the packet. 
Since max(max_allowed_packet) is 1 GB the slave still can't handle the large events exceeding 1 GB even with the fixes of Bug #49931.

Essentially, the master and the slave needs a notion of fragmentation
at sending/receiving time.

That maximum is max_allowed_

How to repeat:
1. Easy way

Create a Rows-log-event size of > max_allow_packet of the slave and replicate it to the slave.
The slave accepts the event which is incorrect.

2. Hard way

Create a Rows-log-event size of > max(max_allow_packet) == 1GB and replicate to
the slave that has max_allowed_packet := 1GB.
According to the client-server protocol docs lines the slave can't accept such packet and that is probably what should happen.
[14 Jul 2010 9:02] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:


3208 Andrei Elkin	2010-07-14
      Bug #55247  	fragmentation layer for transferring over max_allowed_packet rows-event
      the slave still can't handle the large events exceeding 1 GB because of client-server protocol
      limitation but Rows-events larger than 1 GB can be really created.
      This patch represents a sceleton implementation of master-slave fragmentation layer.
      The layer is basically a duo of wrappers for my_net_write() (master) and read_event() (slave). 
      It is supposed to apply to Rows-log events exclusively.
      CAVEAT: not compiled, no tests just for reviewing.
[14 Jul 2010 10:13] Andrei Elkin
For triaging, please keep in mind that the bug conditions apply to over 1 GB size of Rows-events. Those can't be replicated without fixes like in a committed patch today.