MDEV-37608: Increase default binlog_row_event_max_size to 64k

[KhaledSayed04]

Summary:
This PR updates the default value of binlog_row_event_max_size from 8,192 bytes (8k) to 65,536 bytes (64k).

Technical Rationale:
The legacy 8k default causes extreme fragmentation in the binary log when handling modern workloads with large row payloads. By increasing this limit to 64k, the engine can aggregate more rows into fewer Write_rows events.

My benchmarks show that for a transaction involving 1,000 rows (5KB each), the 64k default reduces the number of binary log events from 1,000 to 77—a 92.3% reduction in header and metadata overhead. While 128k offers slightly better aggregation (39 events), 64k represents the optimal balance for memory allocation and network MTU efficiency.

---

Benchmark Results

Test Case: 1,000 rows inserted in a single transaction (5KB payload per row).

Buffer Size (Default)	Write_rows Events	Duration	Efficiency Gain
8192 (Legacy)	1,000	0.297s	-
32768	167	0.294s	~83.3% Fewer Headers
65536 (Proposed)	77	0.287s	~92.3% Fewer Headers
131072	39	0.284s	~96.1% Fewer Headers

---

Test Environment

• CPU: AMD Ryzen 5 PRO 4650G (6 Cores / 12 Threads)
• RAM: 16GB (15Gi Available)
• Storage: Kingston SNVS500G NVMe SSD (ROTA: 0)
• OS: Linux Mint 22.1 (Kernel 6.8.0-54-generic)

---

Verification

• Functional: Passed mtr binlog.binlog_row_binlog.
• Reproducibility: The results can be reproduced using the attached multi-row insert script.

Click to view Benchmark Script

#!/bin/bash

# Configuration
SIZES=(8192 32768 65536 131072)
SOCKET="/tmp/mariadb_bench.sock"
DATADIR="$(pwd)/sql/data"
BINLOG_DIR="$DATADIR"

# Prepare the Payload (1000 rows, 5KB each ~ 5MB total)
echo "Preparing the heavy multi-row payload..."
VALUES_PART=$(for i in {1..999}; do echo -n "(REPEAT('M', 5000)), "; done)
VALUES_PART+="(REPEAT('M', 5000))"
SQL_QUERY="CREATE DATABASE IF NOT EXISTS bench; USE bench; DROP TABLE IF EXISTS t1; CREATE TABLE t1 (id INT PRIMARY KEY AUTO_INCREMENT, d LONGTEXT) ENGINE=InnoDB; INSERT INTO t1 (d) VALUES $VALUES_PART;"

pkill -9 mariadbd
rm -rf "$DATADIR" && mkdir -p "$DATADIR"

echo -e "\n| Size | Events | Duration |"
echo "| :--- | :--- | :--- |"

for VAL in "${SIZES[@]}"; do
    # Start server with specific size
    ./sql/mariadbd --datadir="$DATADIR" --console --skip-grant-tables \
    --binlog-format=ROW --log-bin=mysql-bin --port=3307 \
    --socket="$SOCKET" --binlog_row_event_max_size=$VAL > server.log 2>&1 &
    
    until ./client/mariadb --socket="$SOCKET" -e "SELECT 1" > /dev/null 2>&1; do
        sleep 1
    done

    # Run workload and capture time
    # We use 'bash -c' to ensure 'time' captures only the client execution
    TIME_RESULT=$( { time ./client/mariadb --socket="$SOCKET" -e "$SQL_QUERY" ; } 2>&1 )
    DURATION=$(echo "$TIME_RESULT" | grep "real" | awk '{print $2}')

    # Count Write_rows events
    LOG=$(./client/mariadb --socket="$SOCKET" -e "SHOW MASTER LOGS;" -sN | tail -1 | awk '{print $1}')
    COUNT=$(./client/mariadb-binlog "$BINLOG_DIR/$LOG" | grep "Write_rows" | wc -l)

    # Output result
    echo "| $VAL | $COUNT | $DURATION |"

    # Shutdown for next run
    pkill -9 mariadbd
    sleep 2
done

[CLAassistant]

All committers have signed the CLA.

[gkodinov]

Thank you for your contribution! This is a preliminary review.

Good job on the performance evaluation!

Several things to fix here:

• Please use a single commit
• Make sure the commit message complies to CODING_STANDARDS.md
• Re-record mysql--help to reflect the new value
• (optional) Consider adding a specialized test for this variable, similar to e.g. binlog_cache_size_basic.test

[KhaledSayed04]

Hi @gkodinov,

I've implemented the default change to 64k and added the basic system variable tests.
However, the CI (specifically the Embedded Debug builds) is showing regressions.

These failures occur because of some environment conditions that I couldn't catch. I have ran the failing tests locally and they passed.

Regarding expectations based on the legacy 8k event boundaries for some other tests, I have investigated two ways to resolve this:

• Scaling the Tests: Updating the .test and .inc files to use larger payloads (e.g., 64k+). This is thorough but results in large diffs and might be brittle.
• Pinning the Suites: Adding suite-level my.cnf or individual .opt files to keep these specific tests running at the legacy 8k limit. This preserves the original test logic while allowing the 64k default to take effect everywhere else.

Given that this task was marked as 'beginner-friendly,' the second option (pinning) seems more localized, but I'm happy to perform the full refactor if you prefer the first.

[gkodinov]

Yes, I think pinning should be OK.

[gkodinov]

The embedded failure occurs because of the following:

main.vector 'aria'                       w1 [ fail ]
        Test ended at 2026-02-27 11:26:29
CURRENT_TEST: main.vector
Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown option '--loose-disable-ssl-verify-server-cert'
Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'loose-ssl-ca=/home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/std_data/cacert.pem'
Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'loose-ssl-cert=/home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/std_data/client-cert.pem'
Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'loose-ssl-key=/home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/std_data/client-key.pem'
Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown option '--loose-skip-ssl'
Got ERROR: "/home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'binlog-row-event-max-size=8192'" errno: 2000
mysqltest: Can't initialize MariaDB server

Note how the rest of the variables in the .opt file that are unknown are prefixed with --loose? Although they're not really dynamic. It's because of the embedded case where these are (apparently) not sourced.

[gkodinov]

We're very close. Let's just fix the failing buildbot tests. The rest is fine.

[gkodinov]

prefix with --loose here because it's run in embedded mode.

[KhaledSayed04]

@gkodinov
I've identified that the 64k change causes widespread regressions in legacy suites (Vector, Replication, and Windows Bootstrap) because they rely on specific 8k boundaries.

These tests don't fail all at once when running CI to group them all. They appear one by one.
I have a cleaner solution than adding dozens of .opt files: I can add loose-binlog-row-event-max-size=8192 to mysql-test/include/default_mysqld.cnf. This pins the entire test suite to the legacy limit while allowing the server to adopt 64k globally.

Is modifying default_mysqld.cnf the preferred way to handle such a large-scale test environment mismatch, or should I stick to individual .opt files for the failing tests?

[KhaledSayed04]

To build on my previous comment, I’ve performed a deeper static analysis to identify why some tests (like the Windows bootstrap) fail in CI despite passing in my local environment.

The 64k default creates a "physics shift" in event packing and memory overhead that the legacy test suite is highly sensitive to. I’ve identified the following candidate affected tests that likely require pinning to maintain stability across different architectures (Linux, Windows, etc.):

• Explicit Position-Tracking (47 tests): These tests use commands like SHOW BINLOG EVENTS or master_pos_wait, making them hard-coded to specific byte offsets.

grep -rlE "show binlog events|show master status|master_pos_wait" mysql-test/ | grep "\.test$" | wc -l

• Storage & Row-Ordering (27 tests): These rely on Aria physical packing behavior (e.g., main.vector_aria), which changes with larger event sizes.

grep -rlE "engine=aria" mysql-test/main/ | grep "\.test$" | wc -l

• Buffer & Protocol Constraints (61 tests): These tests manually lower max_allowed_packet or net_buffer_length to values (often to 8k or 16k) that clash with a 64k default. A 64k event default may cause "Packet too large" errors or protocol mismatches that these tests aren't configured to handle.

grep -rlE "max_allowed_packet|net_buffer_length|binlog_cache_size" mysql-test/ | grep "\.test$" | wc -l

• Memory Overhead (123 tests): These track memory-related variables or internal limits; the 64k per-thread cache default increases the base initialization footprint.

grep -rlE "memory" mysql-test/main/ | grep "\.test$" | wc -l

Given that nearly 200 tests are potentially affected by these implicit environment dependencies, I think the single-line addition to mysql-test/include/default_mysqld.cnf is the scalable way to adopt the 64k engine default without drowning the PR in .opt files.

I understand that individual .opt files make requirements explicit. However, given that these 200+ candidates are 'implicitly' dependent on the old default, Path A (global pin) provides a cleaner baseline.

A possible compromise: We could use default_mysqld.cnf for the general stability of the suite, and I can add specific .opt files only for the primary 'Replication' and 'Vector' tests that are most critical for documenting these boundaries. This avoids PR bloat while maintaining documentation where it matters most.

Looking forward to your guidance on which approach aligns best with the MariaDB testing philosophy.

[bnestere]

Hi @KhaledSayed04 !

It is good to update tests for new configurations, as this makes it obvious what problems users may run into when upgrading. Future tests will also more closely resemble our users behaviors. I'd suggest the following:

• Explicit Position-Tracking (47 tests): These tests use commands like SHOW BINLOG EVENTS or master_pos_wait, making them hard-coded to specific byte offsets.
• Storage & Row-Ordering (27 tests): These rely on Aria physical packing behavior (e.g., main.vector_aria), which changes with larger event sizes.
  ...
• Memory Overhead (123 tests): These track memory-related variables or internal limits; the 64k per-thread cache default increases the base initialization footprint.

The above three cases don't seem to rely on binlog_row_event_max_size for any actual behavior, it is just reporting numbers have changed. I'd suggest re-recording the tests to account for the new offset.

• Buffer & Protocol Constraints (61 tests): These tests manually lower max_allowed_packet or net_buffer_length to values (often to 8k or 16k) that clash with a 64k default. A 64k event default may cause "Packet too large" errors or protocol mismatches that these tests aren't configured to handle.

These tests seem to rely on behavior from binlog_row_event_max_size. I think changing/adding a .opt/.cnf file is unfortunately the only way to go about it for these tests.

Otherwise it looks good! If you can fix the tests by March 10, we can get this patch into the upcoming 13.0 preview release.

[KhaledSayed04]

Hi @bnestere !
After extensive testing across all Buildbot environments (including MSAN, Debug, and Windows), the PR is now stabilized.
Technical Note on Test Stability:
While the core logic for the 64k default is robust, I observed that the change in binlog event size significantly altered the I/O and timing profile of the server in Debug/MSAN environments (not the others). This "uncovered" several latent race conditions in legacy tests (notably main.xa and rpl.rpl_row_foreign_key_mdl) that were previously masked by the 8k default timing.
To address this and ensure a clean 13.0 release:

• CI Hardening: I have added explicit synchronization and timing buffers to these tests to make them resilient to the new performance profile.
• Protocol Safety: I have retained .opt pinning for tests setting tiny max_allowed_packet limits. While some runs pass without them, they serve as a necessary safeguard against non-deterministic protocol mismatches in high-latency or memory-constrained environments.

The PR is ready for review.

[gkodinov]

Very close!

Just please remove or explain seemingly unrelated changes.

[bnestere]

Thanks for getting the test fixups started, @KhaledSayed04 !

I've left some additional notes / questions.

[bnestere]

Please add a new line. Also, I saw @gkodinov had already asked about why the non binlog-* option exists, so I won't re-ask. But the convention for .opt files is to keep options on the same line separated by spaces. .cnf files are different however, with new options on separate lines.

[KhaledSayed04]

Is 'Line lengths' convention applied in .opt files too?

Lines should be no more than 80 characters.

[KhaledSayed04]

Cache Boundary & Overflow Handling

These tests utilize a 4KB binlog_cache_size (the server minimum). The 8KB pin ensures that events exceed the memory buffer, forcing the server into the incremental flush-to-disk and overflow logic.
With the 64KB upgrade, the scale between the event size and the 4KB cache is so large (16x) that the server may trigger an "Event too large" rejection during the initial memory allocation phase. Retaining the 8KB limit ensures the server actually attempts to write a partial event to the cache, so that exercising the IO_CACHE spill-to-disk code paths.

Affected Files:

• mysql-test/main/alter_table_online_debug.opt
• mysql-test/suite/binlog/t/binlog_bug23533.opt
• mysql-test/suite/galera/t/galera_binlog_cache_size.opt
• mysql-test/suite/rpl/t/rpl_row_binlog_max_cache_size-master.opt
• mysql-test/suite/rpl/t/rpl_stm_binlog_max_cache_size-master.opt
• mysql-test/suite/rpl/t/rpl_mixed_binlog_max_cache_size-master.opt
• mysql-test/suite/rpl/t/rpl_create_select_row-master.opt

[KhaledSayed04]

Event Fragmentation & Protocol Integrity

These tests verify that large rows are correctly sliced into multiple Rows_log_event fragments. A 64KB default would allow the test payloads to fit into a single event, neutralizing the validation of reassembly and protocol flags.

Affected Files:

• mysql-test/suite/rpl/t/rpl_fragment_row_event_main.cnf
• mysql-test/suite/rpl/t/rpl_loaddata_map-master.opt
• mysql-test/suite/rpl/t/rpl_loaddata_map-slave.opt
• mysql-test/suite/rpl/t/rpl_checksum_cache.opt
• mysql-test/suite/binlog_encryption/rpl_packet.cnf

[KhaledSayed04]

Engine Spills & Recovery (OOB/ENOSPC)

These tests exercise Out-of-Band (OOB) offloading to the storage engine or verify server resilience during Disk Full (ENOSPC) scenarios while flushing the binary log cache.

The 8KB pin is required to maintain the "Small World" math where even a single statement forces a transition from memory to storage. At 64KB, these transactions would remain "in-line" in memory, failing to trigger the temporary file creation, disk-full error injection, and encryption logic that these tests are specifically designed to measure.

Affected Files:

• mysql-test/suite/binlog_in_engine/rpl_oob.opt
• mysql-test/suite/binlog_in_engine/xa.opt
• mysql-test/suite/binlog_in_engine/rpl_dual_cache-master.opt
• mysql-test/suite/rpl/t/rpl_row_binlog_tmp_file_flush_enospc-master.opt
• mysql-test/suite/rpl/t/rpl_mdev-11092.opt
• mysql-test/suite/encryption/t/tempfiles.opt
• mysql-test/suite/perfschema/t/io_cache-master.opt

[KhaledSayed04]

Micro-Rotation & Space Limits

These tests validate how MariaDB purges binary logs or manages temporary space under strict constraints. They utilize limits ranging from "Micro-Thresholds" (e.g., max-binlog-total-size=1500) to moderate session quotas (e.g., max_tmp_session_space_usage=512K).

The 8KB pin is retained to maintain the mathematical proportionality between event size and space limits.

Affected Files:

• mysql-test/suite/rpl/t/max_binlog_total_size-master.opt
• mysql-test/main/tmp_space_usage-master.opt
• mysql-test/suite/rpl/t/rpl_binlog_cache_disk_full_row-master.opt
• mysql-test/suite/binlog/include/binlog_cache_stat.opt

[bnestere]

This looks great, @KhaledSayed04 , thank you!

I have three last very minor requests;

1. A left a comment to add a final line to your new .test file
2. To the git commit message: your PR has great comments to document what tests changed and why, can you add these descriptions to the git commit message? Just copy pasting is fine.
3. Also to the git commit message, please add your reviewers :)

Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
Reviewed-by: Georgi Kodinov <joro@mariadb.org>

Thanks for the great work!

[bnestere]

Please add one last line to specify the end of the test:

Suggested change

	SELECT @@global.binlog_row_event_max_size;
	SELECT @@global.binlog_row_event_max_size;
	--echo # End of sys_vars.binlog_row_event_max_size_basic

[bnestere]

@KhaledSayed04 also, just to set your expectations to our internal process, I've approved this to be in 13.0. It won't yet be merged to the main branch. We will first make a 13.0-preview branch which will include your patch, so both the public and our internal QA team can test it out. Provided there are no issues with the patch (I don't envision there will be any), the 13.0 RC is in May, and that is when we will pull the patch into main.

[KhaledSayed04]

Hi @bnestere, I've pushed the updated commit with the expanded audit in the message and the reviewers added.

I also added the final line to the test file as requested:

add one last line to specify the end of the test:
--echo # End of sys_vars.binlog_row_event_max_size_basic

Quick note on a small cleanup: I removed the general rpl_loaddata_map.opt file that I had added as it was redundant because the 8KB pin is correctly applied in both rpl_loaddata_map-master.opt and rpl_loaddata_map-slave.opt. This ensures the topology is pinned without unnecessary configuration files.

Thank you for the feedback and approval!