1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00

MDEV-5921: In parallel replication, an error is not correctly signalled to the next transaction

When a transaction fails in parallel replication, it should signal the error
to any following transactions doing wait_for_prior_commit() on it. But the
code for this was incorrect, and would not correctly remember a prior error
when sending the signal. This caused corruption when slave stopped due to an
error.

Fix by remembering the error code when we first get an error, and passing the
saved error code to wakeup_subsequent_commits().

Thanks to nanyi607rao who reported this bug on
maria-developers@lists.launchpad.net and analysed the root cause.
This commit is contained in:
unknown
2014-03-21 10:11:28 +01:00
parent e59dec0345
commit a5418c5540
5 changed files with 118 additions and 22 deletions

View File

@ -1053,6 +1053,7 @@ SET GLOBAL slave_parallel_max_queued= @old_max_queued;
--connection server_1
INSERT INTO t3 VALUES (82,0);
SET binlog_format=@old_format;
--save_master_pos
--connection server_2
@ -1113,6 +1114,64 @@ INSERT INTO t3 VALUES (107, rand());
SELECT * FROM t3 WHERE a >= 100 ORDER BY a;
--echo *** MDEV-5921: In parallel replication, an error is not correctly signalled to the next transaction ***
--connection server_2
--source include/stop_slave.inc
SET GLOBAL slave_parallel_threads=10;
--source include/start_slave.inc
--connection server_1
INSERT INTO t3 VALUES (110, 1);
--save_master_pos
--connection server_2
--sync_with_master
SELECT * FROM t3 WHERE a >= 110 ORDER BY a;
# Inject a duplicate key error.
SET sql_log_bin=0;
INSERT INTO t3 VALUES (111, 666);
SET sql_log_bin=1;
--connection server_1
# Create a group commit with two inserts, the first one conflicts with a row on the slave
--connect (con1,127.0.0.1,root,,test,$SERVER_MYPORT_1,)
SET debug_sync='commit_after_release_LOCK_prepare_ordered SIGNAL master_queued1 WAIT_FOR master_cont1';
send INSERT INTO t3 VALUES (111, 2);
--connection server_1
SET debug_sync='now WAIT_FOR master_queued1';
--connect (con2,127.0.0.1,root,,test,$SERVER_MYPORT_1,)
SET debug_sync='commit_after_release_LOCK_prepare_ordered SIGNAL master_queued2';
send INSERT INTO t3 VALUES (112, 3);
--connection server_1
SET debug_sync='now WAIT_FOR master_queued2';
SET debug_sync='now SIGNAL master_cont1';
--connection con1
REAP;
--connection con2
REAP;
SET debug_sync='RESET';
--save_master_pos
--connection server_2
--let $slave_sql_errno= 1062
--source include/wait_for_slave_sql_error.inc
--source include/wait_for_slave_sql_to_stop.inc
# We should not see the row (112,3) here, it should be rolled back due to
# error signal from the prior transaction.
SELECT * FROM t3 WHERE a >= 110 ORDER BY a;
SET sql_log_bin=0;
DELETE FROM t3 WHERE a=111 AND b=666;
SET sql_log_bin=1;
START SLAVE SQL_THREAD;
--sync_with_master
SELECT * FROM t3 WHERE a >= 110 ORDER BY a;
--connection server_2
--source include/stop_slave.inc
SET GLOBAL slave_parallel_threads=@old_parallel_threads;