mariadb/mysql-test/suite/rpl/r/rpl_system_versioning_partitions.result
Kristian Nielsen 7081f2a58e Binlog-in-engine: New binlog implementation integrated in InnoDB
Implement an improved binlog implementation that is integrated into
the storage engine. The new implementation is enabled with the
--binlog-storage-engine option. Initially the InnoDB storage engine
implements the binlog.

Integrating the binlog in the storage engine improves performance,
since it makes the InnoDB redo log the single source of truth and
avoids the need for expensive two-phase commit between binlog and
engine. It also makes it possible to disable durability (set
--innodb-flush-log-at-trx-commit=0) to further improve performance,
while still preserving the ability to recover the binlog and database
into a consistent state after a crash.

The new binlog implementation also greatly improves the internal
design and implementation of the binlog, and enables future
enhancements for replication.

This is a squash of the original 11.4-based patch series.

Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2026-01-23 03:21:03 +01:00

77 lines
2.7 KiB
Text

include/master-slave.inc
[connection master]
#
# Initialize system-versioned and partitioned table and its data
connection slave;
include/stop_slave.inc
connection master;
SET timestamp=UNIX_TIMESTAMP('2025-01-01 01:00:00.000000');
include/kill_binlog_dump_threads.inc
RESET MASTER;
connection slave;
include/start_slave.inc
connection master;
create table t1 (x int) engine=InnoDB with system versioning partition by system_time limit 3 partitions 5;
insert into t1 values(1);
insert into t1 values(2);
insert into t1 values(3);
insert into t1 values(4);
insert into t1 values(5);
# Verifying master partitions are correct after data insertion..
# .. done
connection slave;
connection slave;
# Verifying partitions of master and slave match on data setup..
# .. done
#
# "Delete" each row -- these are the BINLOG commands generated by
# mysqlbinlog from `delete from t1 where x=<n>` statements. Because the
# table uses system versioning and system_time partition, the actual
# events are updates, with added fields for the `row_start` and `row_end`
# columns.
connection master;
# BINLOG for Format Description event
BINLOG '
APZ0Zw8BAAAA/AAAAAABAAAAAAQAMTEuNy4yLU1hcmlhREItZGVidWctbG9nAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA9nRnEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
CgoKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgGuUmo6
';
# BINLOG for delete from t1 where x=1;
BINLOG '
APZ0ZxMBAAAAMQAAAAAAAAAAACEAAAAAAAEABHRlc3QAAnQxAAMDERECBgYBoCHyJQ==
APZ0ZxgBAAAASAAAAAAAAAAAACEAAAAAAAEAAwcH+AEAAABndPYAAAAA/////w9CP/gBAAAAZ3T2
AAAAAGd09gAAAAAuqwNP
';
# BINLOG for delete from t1 where x=2;
BINLOG '
APZ0ZxMBAAAAMQAAAAAAAAAAACEAAAAAAAEABHRlc3QAAnQxAAMDERECBgYBoCHyJQ==
APZ0ZxgBAAAASAAAAAAAAAAAACEAAAAAAAEAAwcH+AIAAABndPYAAAAA/////w9CP/gCAAAAZ3T2
AAAAAGd09gAAAAAsSeT/
';
# BINLOG for delete from t1 where x=3;
BINLOG '
APZ0ZxMBAAAAMQAAAAAAAAAAACEAAAAAAAEABHRlc3QAAnQxAAMDERECBgYBoCHyJQ==
APZ0ZxgBAAAASAAAAAAAAAAAACEAAAAAAAEAAwcH+AMAAABndPYAAAAA/////w9CP/gDAAAAZ3T2
AAAAAGd09gAAAADS6EaQ
';
# BINLOG for delete from t1 where x=4;
BINLOG '
APZ0ZxMBAAAAMQAAAAAAAAAAACEAAAAAAAEABHRlc3QAAnQxAAMDERECBgYBoCHyJQ==
APZ0ZxgBAAAASAAAAAAAAAAAACEAAAAAAAEAAwcH+AQAAABndPYAAAAA/////w9CP/gEAAAAZ3T2
AAAAAGd09gAAAABpi1pF
';
# BINLOG for delete from t1 where x=5;
BINLOG '
APZ0ZxMBAAAAMQAAAAAAAAAAACEAAAAAAAEABHRlc3QAAnQxAAMDERECBgYBoCHyJQ==
APZ0ZxgBAAAASAAAAAAAAAAAACEAAAAAAAEAAwcH+AUAAABndPYAAAAA/////w9CP/gFAAAAZ3T2
AAAAAGd09gAAAACXKvgq
';
# Verifying master partitions are correct after deletion BINLOG stmts..
# .. done
connection slave;
connection slave;
connection master;
drop table t1;
include/rpl_end.inc