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).
Showing
Please register or sign in to comment