Skip to content

MDEV-37229: Set proper trx isolation level before every applied event #4422

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: 10.11
Choose a base branch
from
+56 −1
Open

MDEV-37229: Set proper trx isolation level before every applied event #4422

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions mysql-test/suite/galera/r/galera_binlog_stmt_autoinc.result
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,28 @@ i c
3 dummy_text
5 dummy_text
7 dummy_text
insert into t1(i) values(null);
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system variable that may have a different value on the slave
insert into t1(i) values(null);
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system variable that may have a different value on the slave
insert into t1(i) values(null);
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system variable that may have a different value on the slave
insert into t1(i) values(null);
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system variable that may have a different value on the slave
select * from t1 order by i;
i c
1 dummy_text
3 dummy_text
5 dummy_text
7 dummy_text
9 dummy_text
11 dummy_text
13 dummy_text
15 dummy_text
connection node_2;
show variables like 'auto_increment%';
Variable_name Value
Expand All @@ -44,6 +66,10 @@ i c
3 dummy_text
5 dummy_text
7 dummy_text
9 dummy_text
11 dummy_text
13 dummy_text
15 dummy_text
SET GLOBAL wsrep_forced_binlog_format='none';
connection node_1;
SET GLOBAL wsrep_forced_binlog_format='none';
Expand Down
1 change: 1 addition & 0 deletions mysql-test/suite/galera/t/galera_binlog_stmt_autoinc.cnf
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,5 +5,6 @@ auto_increment_offset=1
auto_increment_increment=2

[mysqld.2]
wsrep_slave_threads=2
auto_increment_offset=2
auto_increment_increment=2
11 changes: 10 additions & 1 deletion mysql-test/suite/galera/t/galera_binlog_stmt_autoinc.test
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,8 +48,17 @@ insert into t1(i) values(null), (null), (null);

select * from t1 order by i;

# Ensure both appliers have some work to perform in parallel.
# This way we can see they both have proper isolation level set.
insert into t1(i) values(null);
insert into t1(i) values(null);
insert into t1(i) values(null);
insert into t1(i) values(null);

select * from t1 order by i;

--connection node_2
--let $wait_condition = SELECT COUNT(*) = 4 FROM t1;
--let $wait_condition = SELECT COUNT(*) = 8 FROM t1;
--source include/wait_condition.inc
show variables like 'auto_increment%';
select * from t1 order by i;
Expand Down
2 changes: 2 additions & 0 deletions sql/sql_plugin.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4545,6 +4545,8 @@ my_bool post_init_callback(THD *thd, void *)

// Restore option_bits
thd->variables.option_bits= option_bits_saved;
// Restore proper default isolation level for appliers.
thd->variables.tx_isolation= ISO_READ_COMMITTED;
}
set_current_thd(0);
return 0;
Expand Down
17 changes: 17 additions & 0 deletions sql/wsrep_applier.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -253,6 +253,19 @@ int wsrep_apply_events(THD* thd,
}
}

/* Statement-based replication requires InnoDB repeatable read
Copy link

@mariadb-TeemuOllakka mariadb-TeemuOllakka Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think some elaboration is needed in this comment:

  • As the transaction is already started in Wsrep_high_priority_service::start_transaction(), is the change of thd->tx_isolation fully effective here or does it just suppress some server level checks?
  • Is it possible that the write set contains both row and query events? In this case a row event could start a transaction with ISO_READ_COMMITTED and the following query event would be actually executed with read-committed isolation as the thd->tx_isolation is effective only when the transaction is started.
  • Should this apply only to DML or also to DDLs (which are replicated as TOI)?

Copy link
Author

@mariadb-DenisProtivensky mariadb-DenisProtivensky Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • it seems that changing the isolation level only affects server transactions that haven't started yet (maybe some extra check should be performed to determine if we have a transaction already running and skip this code)
  • I don't know, but there's a mixed replication setting available. If intermixing row and query events is allowed, then we're in trouble. I don't see a good way of fixing that except we specifically add a documentation statement that such mode should not be used on the producer (master)
  • the isolation level is reset to default after every applied event, so TOI will run with read committed. As we're replicating SQL statements with TOI, maybe read committed is enough? Ideally, we might want to replicate the isolation level used for TOI on the initiator node, but I don't think it's possible right now.

transaction isolation level or higher. */
if (LOG_EVENT_IS_QUERY(typ))
{
thd->variables.tx_isolation= ISO_REPEATABLE_READ;
thd->tx_isolation = ISO_REPEATABLE_READ;
}
else
{
thd->variables.tx_isolation= ISO_READ_COMMITTED;
thd->tx_isolation = ISO_READ_COMMITTED;
}

if (LOG_EVENT_IS_WRITE_ROW(typ) ||
LOG_EVENT_IS_UPDATE_ROW(typ) ||
LOG_EVENT_IS_DELETE_ROW(typ))
Expand Down Expand Up @@ -292,6 +305,10 @@ int wsrep_apply_events(THD* thd,

exec_res= ev->apply_event(thd->wsrep_rgi);

/* Restore applier's default transaction isolation level. */
thd->variables.tx_isolation= ISO_READ_COMMITTED;
thd->tx_isolation = ISO_READ_COMMITTED;

DBUG_PRINT("info", ("exec_event result: %d", exec_res));

if (exec_res)
Expand Down