-
Notifications
You must be signed in to change notification settings - Fork 31
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
PXB-3254 Document reduction in locks
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
1 parent
f546dc9
commit 40182af
Showing
4 changed files
with
80 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. | ||
|
||
|
||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters