--slave-info does not work with --no-lock

Bug #834657 reported by Alexey Kopytov
10
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().

Tags: cr i18185

Related branches

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
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-578

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.