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

Reported by Alexey Kopytov on 2011-08-26
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Medium
Alexey Kopytov
1.6
Medium
Alexey Kopytov
2.0
Medium
Alexey Kopytov
Trunk
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().

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.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers