--slave-info does not work with --no-lock
Bug #834657 reported by
Alexey Kopytov
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
Medium
|
Alexey Kopytov | ||
1.6 |
Fix Released
|
Medium
|
Alexey Kopytov | ||
2.0 |
Fix Released
|
Medium
|
Alexey Kopytov | ||
Trunk |
Fix Released
|
Medium
|
Alexey Kopytov |
Bug Description
innobackupex assumes the only case where --slave-info makes sense (i.e. slave info is consistent with the backup) is when FLUSH TABLES WITH READ LOCK is run on the server. As a result, no slave information is saved when either --no-lock is specified or an incremental backup is being taken, as tables are not locked in those cases.
However, --safe-slave-backup stops the SQL thread before taking a backup and thus, slave info is consistent even for incremental backups or when --no-lock is specified. innobackupex has to be fixed to take that into account by moving the call to write_slave_info() out of mysql_lockall().
Related branches
lp:~akopytov/percona-xtrabackup/bug834657
- Stewart Smith (community): Approve
-
Diff: 63 lines (+33/-1)2 files modifiedinnobackupex (+8/-1)
test/t/ib_slave_info.sh (+25/-0)
lp:~akopytov/percona-xtrabackup/bug834657-1.6
- Stewart Smith (community): Approve
-
Diff: 113 lines (+53/-10)2 files modifiedinnobackupex (+25/-10)
test/t/ib_slave_info.sh (+28/-0)
Changed in percona-xtrabackup: | |
status: | New → In Progress |
assignee: | nobody → Alexey Kopytov (akopytov) |
milestone: | none → 1.6.3 |
Changed in percona-xtrabackup: | |
status: | In Progress → Fix Committed |
tags: | added: cr i18185 |
Changed in percona-xtrabackup: | |
milestone: | 1.6.3 → none |
Changed in percona-xtrabackup: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/ /jira.percona. com/browse/ PXB-578