Merge lp:~akopytov/percona-xtrabackup/bug1081882-2.0 into lp:percona-xtrabackup/2.0
Status: | Merged |
---|---|
Approved by: | Stewart Smith |
Approved revision: | no longer in the source branch. |
Merged at revision: | 493 |
Proposed branch: | lp:~akopytov/percona-xtrabackup/bug1081882-2.0 |
Merge into: | lp:percona-xtrabackup/2.0 |
Prerequisite: | lp:~akopytov/percona-xtrabackup/bug924492-2.0 |
Diff against target: |
13 lines (+3/-0) 1 file modified
src/xtrabackup.c (+3/-0) |
To merge this branch: | bzr merge lp:~akopytov/percona-xtrabackup/bug1081882-2.0 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Stewart Smith (community) | Approve | ||
George Ormond Lorch III (community) | g2 | Approve | |
Review via email: mp+141918@code.launchpad.net |
Description of the change
Bug #1081882: xb_parallel_
The problem was sporadic and rather rare, so one can only guess about
the possible reasons. The most likely reason is partial page writes: if
there is a partially written page in a block, XtraBackup retries for 10
times to re-read before giving up.
Naturally, it may also affects production usage, rather than just
Jenkins builds.
There's no ultimate fix either: regardless of how much time we allow for
a partial page write to complete, there's always a chance it is not
complete before we give up and claim the datafile is corrupted. However,
spinning in a tight loop re-reading the same page(s) doesn't make much
sense either. Given that a partial page write is supposed to be an
extremely rare event during a backup procedure, XtraBackup can wait a
bit longer and sleep between unsuccessful retries.
This fix introduces a 0.1 second delay between read retries, which
allows about 0.9 second for partial page write(s) in the same 1 MB block
to complete.
http://