Merge lp:~akopytov/percona-xtrabackup/i25625-bug1037379-2.0 into lp:percona-xtrabackup/2.0
Status: | Merged |
---|---|
Approved by: | Laurynas Biveinis |
Approved revision: | no longer in the source branch. |
Merged at revision: | 472 |
Proposed branch: | lp:~akopytov/percona-xtrabackup/i25625-bug1037379-2.0 |
Merge into: | lp:percona-xtrabackup/2.0 |
Diff against target: |
205 lines (+131/-9) 3 files modified
innobackupex (+21/-9) test/inc/common.sh (+41/-0) test/t/bug1037379.sh (+69/-0) |
To merge this branch: | bzr merge lp:~akopytov/percona-xtrabackup/i25625-bug1037379-2.0 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Laurynas Biveinis (community) | Approve | ||
Review via email: mp+129931@code.launchpad.net |
Description of the change
Bug #1037379: SQL_THREAD left in stopped state of
Bug #887803: innobackupex --safe-
work
The problem in bug #1037379 was that wait_for_
innobackupex ran START/STOP SLAVE SQL_THREAD in a loop. If it succeeded
in getting slave_open_
SQL thread was then started later after copying non-transactional
data. However, when it reached the timeout it did not restart the SQL
thread before terminating with an error.
Another problem was that if wait_for_
innobackupex would start the SQL thread regardless of its initial
state. Which might be an undesired side effect.
Fixed by:
1. Checking the initial SQL thread state and starting it before
terminating with a timeout error in wait_for_
2. Starting the SQL thread only if it was running initially in backup()
Additionally, this revision also fixes bug #887803, because the test
case for bug #1037379 requires a working --safe-
option.
Issue #25625.