Uploaded image for project: 'Percona XtraBackup'
  1. Percona XtraBackup
  2. PXB-605

LP #1075444: [Documentation] Caveats with --no-lock should be clearly mentioned

    Details

    • Type: Bug
    • Status: Done
    • Priority: High
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Documentation
    • Labels:

      Description

      **Reported in Launchpad by Raghavendra D Prabhu last update 22-01-2013 01:00:37

      Currently it states:

      """
      --no-lock

      Use this option to disable table lock with FLUSH TABLES WITH READ LOCK. Use it only if ALL your tables are InnoDB and you DO NOT CARE about the binary log position of the backup. If you are considering to use --no-lock because your backups are failing to acquire the lock, this could be because of incoming replication events preventing the lock from succeeding. Please try using --safe-slave-backup to momentarily stop the replication slave thread, this may help the backup to succeed and you then dont need to resort to using --no-lock.

      """

      I think the condition of no DDL being executed should also be added, running a DDL otherwise during --no-lock + innobackupex can lead to inconsistencies. Reasons for that can also be added to explain why (DDL is non-transactional, hence ibd file creation not recorded in redo logs etc)

        Smart Checklist

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                lpjirasync lpjirasync (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: