Merge lp:~akopytov/percona-xtrabackup/bug1170806-2.1 into lp:percona-xtrabackup/2.1
Status: | Merged |
---|---|
Approved by: | Laurynas Biveinis |
Approved revision: | no longer in the source branch. |
Merged at revision: | 562 |
Proposed branch: | lp:~akopytov/percona-xtrabackup/bug1170806-2.1 |
Merge into: | lp:percona-xtrabackup/2.1 |
Diff against target: |
52 lines (+11/-12) 1 file modified
src/xtrabackup.cc (+11/-12) |
To merge this branch: | bzr merge lp:~akopytov/percona-xtrabackup/bug1170806-2.1 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Laurynas Biveinis (community) | Approve | ||
George Ormond Lorch III (community) | g2 | Approve | |
Review via email: mp+160662@code.launchpad.net |
Description of the change
Bug #1170806: innobackupex continuing with FTWRL even when xtrabackup
The problem was that when the log copying thread failed, it did not
terminate the xtrabackup process immediately. Instead only the log
copying thread was terminated. The main xtrabackup thread would later
check if the 'log_copying_
process, but that happened later, after xtrabackup was done with copying
InnoDB files and signaled innobackupex to lock tables and proceed with
copying non-InnoDB files.
The fix is to terminate the entire xtrabackup process immediately on log
copying failure. There is no reasons to delay checking its status
and fail much later.
http://
See 2.0 review.