Merge lp:~laurynas-biveinis/percona-server/bug1012715-5.1 into lp:percona-server/5.1
Status: | Superseded |
---|---|
Proposed branch: | lp:~laurynas-biveinis/percona-server/bug1012715-5.1 |
Merge into: | lp:percona-server/5.1 |
Diff against target: |
281 lines (+186/-38) 5 files modified
Percona-Server/mysql-test/suite/rpl/r/rpl_percona_crash_resistant_rpl.result (+42/-0) Percona-Server/mysql-test/suite/rpl/t/rpl_percona_crash_resistant_rpl-slave.opt (+1/-0) Percona-Server/mysql-test/suite/rpl/t/rpl_percona_crash_resistant_rpl.test (+95/-0) Percona-Server/storage/innodb_plugin/handler/ha_innodb.cc (+31/-20) Percona-Server/storage/innodb_plugin/trx/trx0trx.c (+17/-18) |
To merge this branch: | bzr merge lp:~laurynas-biveinis/percona-server/bug1012715-5.1 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Laurynas Biveinis (community) | Needs Fixing | ||
Review via email: mp+112346@code.launchpad.net |
This proposal has been superseded by a proposal from 2012-06-29.
Description of the change
Fix bug 1012715 (Crash resistant replication breaks with binlog XA
transaction recovery). The cause is that slave position is recorded
to InnoDB transaction system header at the XA COMMIT stage. If a
crash happens between XA PREPARE and COMMIT stages, the prepared
InnoDB transaction will not have the slave position recorded and thus
will fail to update it once it is replayed during binlog crash
recovery. The slave log position update is inherent part of changes
made by transaction, thus the correct place is the XA PREPARE stage.
- Store the slave log positions to the current InnoDB transaction in
innobase_
- Write the slave log positions in the current InnoDB transaction to
the transaction system header page in trx_prepare_
instead of trx_commit_
- New crash injection site "crash_
innobase_commit() that triggers just before the "real" transaction
commits.
- New test case rpl_percona_
fix and the feature in general.
Jenkins: http://
Issue #22478
Found one issue myself.
The testcase has one sync bug: lines 88--91 do not sync slave with master first, thus might result in slave shutdown while slave SQL thread is still executing.