myisam tables are not locked during incremental backup

Bug #771981 reported by Valentine Gostev on 2011-04-27
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to
Fix Released
Valentine Gostev
Fix Released
Alexey Kopytov
Fix Released
Valentine Gostev

Bug Description

When we are running incremental backup with innobackupex MyISAM tables are not locked, even if we do not specify option --no-lock

364 if (!$option_incremental) {
 374 mysql_lockall() if !$option_no_lock;
 376 }

Related branches

description: updated
Changed in percona-xtrabackup:
importance: Undecided → Critical
assignee: nobody → Valentine Gostev (core-longbow)
Valentine Gostev (longbow) wrote :

This also causes that slave info file is not written when --slave-info specified, because write_slave_info() subroutine is called from mysql_lockall()

Changed in percona-xtrabackup:
status: New → Confirmed
milestone: none → 1.7
tags: added: innobackupex
Rajaram Satyanarayanan (rajs) wrote :

Any planned date for 1.7 release.

Stewart Smith (stewart) wrote :
Changed in percona-xtrabackup:
assignee: Valentine Gostev (longbow) → nobody
status: Confirmed → Triaged
Stewart Smith (stewart) wrote :

Does the merge req linked to this bug report fix the problem? i.e. should this bug now be Fix Committed?

Changed in percona-xtrabackup:
status: Triaged → Fix Committed
Stewart Smith (stewart) on 2011-06-12
Changed in percona-xtrabackup:
status: Fix Committed → Fix Released
Stewart Smith (stewart) on 2011-06-28
Changed in percona-xtrabackup:
assignee: nobody → Valentine Gostev (longbow)
Dave Hall (davidjhall) wrote :

I'm receiving the bug message from the other attached error:
innobackupex-1.5.1: Error: Broken pipe at /usr/bin/innobackupex-1.5.1 line 336

When I try to install xtrabackup 1.6.3 to get around this, it still installs innobackupex 1.5.1
Is there a way to get this patch to fix the incremental problem? Is 1.6.3 supposed to come with the latest innobackupex?
If not, is there a release date for 1.7 where it says this bug will be fixed.

Kenny Gryp (gryp) wrote :

Dave: xtrabackup 1.6.3 comes with a script named innobackupex-1.5.1. The version of that script will not change, for backwards compatibility.
use 'xtrabackup --version' to get the version you have installed.

Alexey Kopytov (akopytov) wrote :

We should consider backporting the fix to 1.6.

Stewart Smith (stewart) wrote :

I'm going to mark this as Won't fix for 1.6 as a fix is available in a later release. If somebody needs this for 1.6, contact us (Percona) and we can organise something.

Stewart Smith (stewart) wrote :

  appears to possibly have already been applied... the patch doesn't apply
  straight on 1.6 and a quick glance at the code looks like it may have
  gotten fixed with some other fixes. Marking as Invalid for 1.6 unless somebody can prove otherwise.

Alexey Kopytov (akopytov) wrote :

The bug is still there:

    if (!$option_incremental && !$option_no_lock) {
        # make a prep copy before locking tables, if using rsync

        # flush tables with read lock

I.e. there's no FTWRL for incremental backups.

Percona now uses JIRA for bug reports so this bug report is migrated to:

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

Duplicates of this bug

Other bug subscribers