Skip to content

Commit

Permalink
PXB-3254 Document reduction in locks
Browse files Browse the repository at this point in the history
	modified:   docs/lock-options.md
	new file:   docs/reduction-in-locks.md
	modified:   docs/xtrabackup-option-reference.md
	modified:   mkdocs-base.yml
  • Loading branch information
alina-derkach-oaza committed Oct 30, 2024
1 parent f546dc9 commit 40182af
Show file tree
Hide file tree
Showing 4 changed files with 80 additions and 7 deletions.
5 changes: 4 additions & 1 deletion docs/lock-options.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,9 @@
# lock-ddl-per-table option improvements

!!! important

The lock-ddl-per-table option is deprecated in Percona Server for MySQL 8.0. Use --lock-ddl instead of this variable.

To block DDL statements on an instance, Percona Server implemented LOCK
TABLES FOR BACKUP. Percona XtraBackup uses this lock for the
duration of the backup. This lock does not affect DML statements.
Expand Down Expand Up @@ -60,4 +64,3 @@ The following improvements have been added:

* A `SELECT` query that acquires an MDL does not retrieve any data.


65 changes: 65 additions & 0 deletions docs/reduction-in-locks.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Reduced backup lock time

!!! important

The `--lock-ddl=REDUCED` option is a [tech preview](./glossary.md#tech-preview). Before using this option in production, we recommend that you test restoring production from physical backups in your environment, and also use the alternative backup method for redundancy.

Percona Server for MySQL implemented `LOCK TABLES FOR BACKUP` to block Data Definition Language (DDL) statements on a server. Percona XtraBackup utilizes this lock during the backup process to ensure that any `DDL` event does not corrupt the backup. The lock does not affect the Data Manipulation Language (DML) statements.

## How the backup lock works

With the [`--lock-ddl=ON`](./xtrabackup-option-reference.md/#lock-ddl) option the backup lock is enabled by default from the start of the backup process.

* Set a backup lock: Set a backup lock on the server to prevent any `DDL` operations, ensuring no new tables are created, renamed, or dropped during the backup.

* Copy the redo logs: Transfer all redo logs from the checkpoint up to the current Log Sequence Number (LSN) and start tracking new entries.

* Identify and copy all InnoDB tablespace, `.ibd`, files. This step takes most of the time and is performed under the lock.

* Copy non-InnoDB files.

* Gather sync point: Collect synchronization points from all engines (InnoDB LSN, binlog, Global Transaction Identifier (GTID), etc.) by querying the log status.

* Stop the redo follow thread: Cease the redo fllow thread once it has copied up to the sync point.

* Release the backup lock on the server.

If the backup lock is disabled with the [`--lock-ddl=OFF`](./xtrabackup-option-reference.md/#lock-ddl) option, a backup continues while concurrent DDL events are executed. Such backups are invalid and fail at `--prepare` step.

## The `--lock-ddl=REDUCED` option overview

[Percona XtraBackup 8.4.0-2](./release-notes/8.4.0-2.md) adds the [`--lock-ddl=REDUCED`](./xtrabackup-option-reference.md/#lock-ddl) option to reduce the time the instance remains under the backup lock. The backup lock is now taken after copying the `.ibd` files and before copying the `non-InnoDB` files.

Copying the InnoDB files with the `--lock-ddl=REDUCED` option is split into two stages.

`Operations performed without the lock`

1. Copying all redo logs from checkpoint up to the current LSN and start following new entries.
2. Start the redo log thread.
3. Tracking file operations from the redo log.
4. Copying of all .ibd without taking any lock.
5. Acquiring Low-traffic Flush Barrier (LTFB)/Low-traffic Insert Barrier (LIFB). This step ensures no new DDL operations, such as creating or altering tables, will occur.
6. Quering the log_status to discover the LSN. This step ensures that all subsequent operations are tracked and that the backup process captures a consistent state of the database.
7. Copying all InnoDB files.
8. Ensuring the redo log has catch up to LSN from step 5.

`Operations performed under the lock`

9. Checking the file operations that were tracked and recopying the tablespaces.
10. Creating additional `meta` files to perform the required actions (deletions or renames) on the already copied files. This approach ensures that the backup remains consistent and accurate without disrupting the streaming process. This step is required for taking streaming backups.
11. Gathering a sync point from all engines (InnoDB LSN, binlog, GTID, etc.) by querying the `log_status`.
12. Stoping the redo follow thread once it copies at least up to sync point at step 11.
13. Releasing LTFB/LIFB.
14. Processing the new files during `--prepare` phase before crash recovery starts.

The `--lock-ddl=REDUCED` option key features are as follows:

* Reduced locking: Instead of holding a full `LOCK TABLES FOR BACKUP` for the entire duration of the backup, it only locks the tables for a shorter period after copying the InnoDB files.

* DDL statements: It allows some `DDL` statements to proceed, reducing the downtime and impact on the database operations.

* Consistency: Ensures that the backup remains consistent by carefully timing the locks to avoid conflicts with ongoing DDL operations.




15 changes: 10 additions & 5 deletions docs/xtrabackup-option-reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,6 @@ $ xtrabackup --prepare --target-dir=/data/backup/mysql/
For all modes, the default options are read from the xtrabackup and
mysqld configuration groups from the following files in the given order:
1. `/etc/my.cnf`
Expand Down Expand Up @@ -598,18 +597,24 @@ Usage: `--lock-ddl`
Enabled by default to ensure that any DDL event does not corrupt the backup. Any DML events continue to occur. A DDL lock protects table and view definitions.
If the option is disabled, a backup continues while concurrent DDL events are executed. These backups are invalid and fail in the Prepare step.
The available values are the following:
|Option| Description|
|`--lock-ddl=ON`| The backup lock is enabled and is taken at the beginning of the backup.|
|`--lock-ddl=OFF`|The backup lock is not taken.|
|`--lock-ddl=REDUCED`|This option value is a [tech preview](./glossary.md#tech-preview). The option value has been added in [Percona XtraBackup 8.4.0-2](./release-notes/8.4.0-2.md) to reduce the time the instance remains under backup lock. The backup lock is taken after copying the `.ibd` files and before copying the `non-InnoDB` files.|
If the option is disabled, a backup continues while concurrent DDL events are executed. These backups are invalid and fail at `--prepare` step.
Use a [safe-slave-backup](#safe-slave-backup) option to stop a SQL replica thread before copying the InnoDB files.
### lock-ddl-per-table
Usage: `--lock-ddl-per-table`
Deprecated. Use the [`–lock-ddl`](#lock-ddl) option instead
Deprecated in Percona XtraBackup 8.0. Use the [`–lock-ddl`](#lock-ddl) option instead
<!--26-1-24-->
Lock DDL for each table before xtrabackup starts to copy
it and until the backup is completed.
Lock DDL for each table before xtrabackup starts to copy it and until the backup is completed.
### lock-ddl-timeout
Expand Down
2 changes: 1 addition & 1 deletion mkdocs-base.yml
Original file line number Diff line number Diff line change
Expand Up @@ -159,14 +159,14 @@ nav:
- lru-dump-backup.md
- throttling-backups.md
- store-backup-history.md
- reduction-in-locks.md
- Prepare features:
- dictionary-cache.md
- Restore features:
- point-in-time-recovery.md
- restore-individual-tables.md
- flush-tables-with-read-lock.md
- log-enhancements.md
- lock-options.md
- smart-memory-estimation.md
- working-with-binary-logs.md
- Binaries:
Expand Down

0 comments on commit 40182af

Please sign in to comment.