innobackupex fails during backup if table is removed while copying
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
Undecided
|
Lachlan Mulcahy | ||
1.6 |
Fix Released
|
Undecided
|
Lachlan Mulcahy | ||
2.0 |
Fix Released
|
Undecided
|
Lachlan Mulcahy |
Bug Description
While running an incremental backup through innobackupex, you can get an error when the script is attempting to copy all the MYI/MYD/...etc files if a table is removed during the process of copying each file.
This occurs as a result of a race condition..
The code works like this;
files = get list of files to copy
foreach( file as files ) {
copy file from source to destination
if we got an error, die with an error.
}
The problem with the above is that when there are a lot of files, a table can conceivably exist at the point in time where the list of files to copy is pulled, but have been removed before the attempt to copy the file is made. For example, a table that exists for a short amount of time.
innobackupex should gracefully handle this, by only throwing an error if the copy failed and the file actually exists.
Related branches
- Alexey Kopytov (community): Approve
-
Diff: 49 lines (+30/-2)1 file modifiedinnobackupex (+30/-2)
- Percona core: Pending requested
-
Diff: 49 lines (+30/-2)1 file modifiedinnobackupex (+30/-2)
- Percona core: Pending requested
-
Diff: 49 lines (+30/-2)1 file modifiedinnobackupex (+30/-2)
Changed in percona-xtrabackup: | |
assignee: | nobody → Lachlan Mulcahy (lachlan-mulcahy) |
status: | New → Fix Committed |
milestone: | none → 1.6.5 |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/ /jira.percona. com/browse/ PXB-1148