mariadb/mysql-test/suite/rpl/r/rpl_start_stop_slave.result

41 lines
802 B
Text
Raw Normal View History

stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
create table t1(n int);
stop slave;
start slave;
stop slave io_thread;
start slave io_thread;
drop table t1;
Bug#38205 Row-based Replication (RBR) causes inconsistencies: HA_ERR_FOUND_DUP Bug#319 if while a non-transactional slave is replicating a transaction possible problem It is impossible to roll back a mixed engines transaction when one of the engine is non-transaction. In replication that fact is crucial because the slave can not safely re-apply a transction that was interrupted with STOP SLAVE. Fixed with making STOP SLAVE not be effective immediately in the case the current group of replication events has modified a non-transaction table. In order for slave to leave either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id. mysql-test/suite/bugs/r/rpl_bug38205.result: bug#38205 non-deterministic part of tests results. mysql-test/suite/bugs/t/rpl_bug38205.test: bug#38205 non-deterministic part of tests. mysql-test/suite/rpl/r/rpl_start_stop_slave.result: bug#38205 deterministic part of tests results. mysql-test/suite/rpl/t/rpl_start_stop_slave-slave.opt: increasing `innodb_lock_wait_timeout' to make the test pass on slow env w/o timeout expired issue. mysql-test/suite/rpl/t/rpl_start_stop_slave.test: bug#38205 deterministic part of tests. sql/log_event.cc: Augmenting row-based events applying with the notion of thd->transaction.{all,stmt}.modified_non_trans_table. The pair is set and reset according to its specification for the mixed transaction processing. Particualry, once `modified_non_trans_table' is set in the row-events processing loop, it will remain till the commit of the transaction. sql/slave.cc: Consulting `thd->transaction.all.modified_non_trans_table' to decide whether to terminate by the sql thread or to continue even though the sql thread might have been STOP-ed (rli->abort_slave).
2009-03-26 10:25:06 +02:00
create table t1i(n int primary key) engine=innodb;
create table t2m(n int primary key) engine=myisam;
begin;
insert into t1i values (1);
insert into t1i values (2);
insert into t1i values (3);
commit;
begin;
insert into t1i values (5);
begin;
insert into t1i values (4);
insert into t2m values (1);
insert into t1i values (5);
commit;
zero
0
stop slave;
rollback;
*** sql thread is *not* running: No ***
Bug#38205 Row-based Replication (RBR) causes inconsistencies: HA_ERR_FOUND_DUP Bug#319 if while a non-transactional slave is replicating a transaction possible problem It is impossible to roll back a mixed engines transaction when one of the engine is non-transaction. In replication that fact is crucial because the slave can not safely re-apply a transction that was interrupted with STOP SLAVE. Fixed with making STOP SLAVE not be effective immediately in the case the current group of replication events has modified a non-transaction table. In order for slave to leave either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id. mysql-test/suite/bugs/r/rpl_bug38205.result: bug#38205 non-deterministic part of tests results. mysql-test/suite/bugs/t/rpl_bug38205.test: bug#38205 non-deterministic part of tests. mysql-test/suite/rpl/r/rpl_start_stop_slave.result: bug#38205 deterministic part of tests results. mysql-test/suite/rpl/t/rpl_start_stop_slave-slave.opt: increasing `innodb_lock_wait_timeout' to make the test pass on slow env w/o timeout expired issue. mysql-test/suite/rpl/t/rpl_start_stop_slave.test: bug#38205 deterministic part of tests. sql/log_event.cc: Augmenting row-based events applying with the notion of thd->transaction.{all,stmt}.modified_non_trans_table. The pair is set and reset according to its specification for the mixed transaction processing. Particualry, once `modified_non_trans_table' is set in the row-events processing loop, it will remain till the commit of the transaction. sql/slave.cc: Consulting `thd->transaction.all.modified_non_trans_table' to decide whether to terminate by the sql thread or to continue even though the sql thread might have been STOP-ed (rli->abort_slave).
2009-03-26 10:25:06 +02:00
*** the prove: the stopped slave has finished the current transaction ***
five
5
zero
0
one
1
include/start_slave.inc
Bug#38205 Row-based Replication (RBR) causes inconsistencies: HA_ERR_FOUND_DUP Bug#319 if while a non-transactional slave is replicating a transaction possible problem It is impossible to roll back a mixed engines transaction when one of the engine is non-transaction. In replication that fact is crucial because the slave can not safely re-apply a transction that was interrupted with STOP SLAVE. Fixed with making STOP SLAVE not be effective immediately in the case the current group of replication events has modified a non-transaction table. In order for slave to leave either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id. mysql-test/suite/bugs/r/rpl_bug38205.result: bug#38205 non-deterministic part of tests results. mysql-test/suite/bugs/t/rpl_bug38205.test: bug#38205 non-deterministic part of tests. mysql-test/suite/rpl/r/rpl_start_stop_slave.result: bug#38205 deterministic part of tests results. mysql-test/suite/rpl/t/rpl_start_stop_slave-slave.opt: increasing `innodb_lock_wait_timeout' to make the test pass on slow env w/o timeout expired issue. mysql-test/suite/rpl/t/rpl_start_stop_slave.test: bug#38205 deterministic part of tests. sql/log_event.cc: Augmenting row-based events applying with the notion of thd->transaction.{all,stmt}.modified_non_trans_table. The pair is set and reset according to its specification for the mixed transaction processing. Particualry, once `modified_non_trans_table' is set in the row-events processing loop, it will remain till the commit of the transaction. sql/slave.cc: Consulting `thd->transaction.all.modified_non_trans_table' to decide whether to terminate by the sql thread or to continue even though the sql thread might have been STOP-ed (rli->abort_slave).
2009-03-26 10:25:06 +02:00
drop table t1i, t2m;