-
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 0ad85a6
Showing
5 changed files
with
122 additions
and
69 deletions.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
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,106 @@ | ||
# Reduced backup lock time | ||
|
||
--8<--- "pro-build-announcement.md" | ||
|
||
!!! 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 XtraBackup 8.4.0-2](./release-notes/8.4.0-2.md) adds the [`--lock-ddl=REDUCED`](#how-the---lock-ddlreduced-option-works) option to reduce the time the server remains locked by `xtrabackup` during full and incremental backups. Now, you can execute `Data Definition Language` (DDL) operations while the backup is in progress. | ||
|
||
### Benefits | ||
|
||
The `--lock-ddl=REDUCED` option key features are as follows: | ||
|
||
* Rather than holding the backup lock throughout the entire backup process, the lock is only acquired for a very short period. | ||
|
||
* DDL operations are allowed on the server while the backup is in progress. | ||
|
||
* The redo log tracks all file operations to maintain consistency. The backup process creates new metadata files to ensure data remains intact. When you run `--prepare`, the system first processes these metadata files to create a consistent database state. | ||
|
||
### Limitations | ||
|
||
* Disk read and write operations are performed during the execution of `DDL` operations and while backing up data using `xtrabackup`. Both types of operations involve accessing and modifying the data stored on disk, which can be resource-intensive. | ||
|
||
* Backups may be larger because new `DDL` operations are executed concurrently on the server, and the files they generate are included in the backup. Additionally, certain `DDL` operations, such as `ADD INDEX` or encryption changes to existing data files, will cause these data files to be recopied, further increasing the backup size. | ||
|
||
* The number of open file handles in your operating system should be configured to match the number of files in the server data directory. | ||
|
||
## How the backup lock with the `--lock-ddl` option works | ||
|
||
Percona Server for MySQL implemented `LOCK TABLES FOR BACKUP` to block `DDL` operations on a server. Percona `xtrabackup` utilizes this lock during the backup process to ensure that any `DDL` operation does not corrupt the backup. With MySQL-compatible servers `xtrabackup` utilizes `Lock Instance For Backup` to lock the server during the backup. The lock does not affect the `Data Manipulation Language` (DML) operations. | ||
|
||
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. | ||
{ .power-number } | ||
|
||
1. Set a backup lock on the server to prevent any DDL operations, such as creating or altering tables. | ||
|
||
2. Parse and copy the redo logs from the checkpoint up to the current `Log Sequence Number` (LSN), and start tracking new file operations. | ||
|
||
3. Identify and copy the `.ibd` files. | ||
|
||
4. Copy `non-InnoDB` files. | ||
|
||
5. Gather a sync point from all engines (InnoDB LSN, binlog, Global Transaction Identifier (GTID), etc.) by querying the log status. | ||
|
||
6. Stop the redo thread once it copies at least up to sync point. | ||
|
||
7. 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 operations are executed. These backups may be invalid and may fail at either the `backup` or the `--prepare` step. | ||
|
||
## How the `--lock-ddl=REDUCED` option works | ||
|
||
Taking backup with the `--lock-ddl=REDUCED` option includes the following phases: | ||
|
||
### Phase 1: Operations performed without the lock | ||
|
||
!!! warning | ||
|
||
The `ALTER INSTANCE ROTATE MASTER KEY` command should not be executed during Phase 1 if there are encrypted tables, as it will cause the backup to fail. | ||
|
||
The following operations are performed without the lock: | ||
{ .power-number } | ||
|
||
1. Parse and copy the redo logs from the checkpoint up to the current `LSN`, and start tracking new file operations. | ||
2. Start the redo log thread to copy the redo logs. | ||
3. Track file operations by parsing the `MLOG_FILE_*` records from the redo log. These records help track changes in the files being backed up to ensure consistency. | ||
4. Copy the `.ibd` files. | ||
|
||
### Phase 2: Operations performed under the lock | ||
|
||
The following operations are performed under the lock: | ||
{ .power-number } | ||
|
||
1. Set the backup lock on the server to prevent new DDL operations, such as creating or altering tables. | ||
2. Check the file operations that were tracked and recopy the tablespaces. | ||
3. Create additional `metadata` 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 is particularly important for streaming backups. | ||
4. Gather a sync point from all engines (InnoDB LSN, binlog, GTID, etc.) by querying the `log_status`. | ||
5. Stop the redo thread once it copies at least up to sync point at step 4. | ||
6. Release the backup lock on the server. | ||
|
||
??? note "The list of metadata files" | ||
|
||
| File | Description | | ||
|--------------|------------------------------------------------------------------------------------------------------------------| | ||
| `.new` | For files that need to be recopied due to encryption or `ADD INDEX` operations. | | ||
| `.del` | For deleted files. If a file has been copied, create a `space_id.del` file. | | ||
| `.ren` | For renamed files after copying. Create a `space_id.ren` file. | | ||
| `.crpt` | For files that cannot be fully copied due to encryption changes. These files will be recopied, and a `.crpt` file will be created for the existing file. | | ||
| `.new.meta` | Similar to `.new`, but for incremental backups. | | ||
| `.new.delta` | Similar to `.new`, but for incremental backups. Create `t1.ibd.meta` and `t1.ibd.delta` instead of `t1.ibd`. | | ||
|
||
### Phase 3. Handling new metadata files in `--prepare` | ||
|
||
The following operations are performed to ensure data remains intact and consistent: | ||
{ .power-number } | ||
|
||
1. Remove the `.crpt` files that match the name after stripping the extension. This step is crucial before the `IBD` scan because these files are incomplete (they can be zero size). | ||
2. Perform a scan to create a mapping of `space_id` to file names. | ||
3. Delete the file matching the `space_id` using `space_id.del`. In case of incremental backups, also delete the corresponding `.new.meta` and `.new.delta` files. | ||
4. Rename the file matching the `space_id` to the name specified in the file using `space_id.ren`. | ||
5. Replace the file that matches the name without the `.new` extension using the `.new` extension. | ||
6. Replace the `meta` and `delta` files that match the name without the `.new` in the name using `.new.meta` and `.new.delta`. | ||
|
||
After `Phase 3` is completed, the regular crash recovery starts. | ||
|
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
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,3 @@ | ||
Percona XtraBackup Pro includes the [capabilities](pxb-pro.md#capabilities) that are typically requested by large enterprises. Percona XtraBackup Pro contains packages created and tested by Percona. These packages are supported only for Percona Customers with a subscription. | ||
|
||
[Become a Percona Customer](https://www.percona.com/about/contact){.md-button} |