Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
MDEV-32570 (added to 12.3) added a new binlog event type, Partial_rows_log_event, to support fragmenting large ROW log events into groups of these smaller event type, that when their content is put together, will recreate the original ROW log event. This happens when writing the events to the binary log itself, i.e. if a transaction produces large amounts of ROW data, then the server will write Partial_rows_log_event s into the binary log.
This doesn't work with the new in-engine binlog added in MDEV-34705 (also added to 12.3). The in-engine binlog write mechanism spills row data changes to the binary log as out-of-band chunks as pages become full. To support replication (i.e. sending this data to slaves), the server still needs to support ROW events as if nothing changed. To support this, the patch created a new binlog_reader API to read these out-of-band chunks and use them to create a regular ROW event. This ROW event still must conform to both limitations tackled by MDEV-32570 (i.e. 1) it must not exceed slave_max_allowed_packet to be transmitted to the slave, and 2) it must not have more than 4GB of data to conform to the ROW event type header size limitation).
This logic added by MDEV-34705 to create a ROW event from out-of-band chunks of binlog data should be extended to support Partial_rows_log_event s, so the server can transmit large transactions to the slave when configured with --binlog-storage-engine=innodb.
Attachments
Issue Links
- split from
-
MDEV-32570 Fragment ROW replication events larger than max_packet_size
-
- Closed
-
-
MDEV-34705 Improving performance of binary logging by removing the need of syncing it
-
- Closed
-