Merge lp:~akopytov/percona-xtrabackup/bug1170806-2.1 into lp:percona-xtrabackup/2.1

Proposed by Alexey Kopytov
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
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
                  failed

    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_succeed' flag is FALSE, and terminated the
    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://jenkins.percona.com/view/XtraBackup/job/percona-xtrabackup-2.1-param/272/

To post a comment you must log in.
Revision history for this message
George Ormond Lorch III (gl-az) wrote :

See 2.0 review.

review: Approve (g2)
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/xtrabackup.cc'
2--- src/xtrabackup.cc 2013-04-24 12:46:07 +0000
3+++ src/xtrabackup.cc 2013-04-24 14:21:53 +0000
4@@ -142,7 +142,6 @@
5 lsn_t log_copy_scanned_lsn;
6 ibool log_copying = TRUE;
7 ibool log_copying_running = FALSE;
8-ibool log_copying_succeed = FALSE;
9
10 ibool xtrabackup_logfile_is_renamed = FALSE;
11
12@@ -2173,17 +2172,22 @@
13
14 counter++;
15 if(counter >= SLEEPING_PERIOD * 5) {
16- if(xtrabackup_copy_logfile(log_copy_scanned_lsn, FALSE))
17- goto end;
18+
19+ if(xtrabackup_copy_logfile(log_copy_scanned_lsn,
20+ FALSE)) {
21+ exit(EXIT_FAILURE);
22+ }
23+
24 counter = 0;
25 }
26 }
27
28 /* last copying */
29- if(xtrabackup_copy_logfile(log_copy_scanned_lsn, TRUE))
30- goto end;
31-
32- log_copying_succeed = TRUE;
33+ if(xtrabackup_copy_logfile(log_copy_scanned_lsn, TRUE)) {
34+
35+ exit(EXIT_FAILURE);
36+ }
37+
38 end:
39 log_copying_running = FALSE;
40 my_thread_end();
41@@ -3176,11 +3180,6 @@
42 }
43 msg("\n");
44
45- if (!log_copying_succeed) {
46- msg("xtrabackup: Error: log_copying_thread failed.\n");
47- exit(EXIT_FAILURE);
48- }
49-
50 /* Signal innobackupex that log copying has stopped and it may now
51 unlock tables, so we can possibly stream xtrabackup_logfile later
52 without holding the lock. */

Subscribers

People subscribed via source and target branches

to all changes: