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

docs/lock-options.md

@@ -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.
@@ -60,4 +64,3 @@ The following improvements have been added:
 
 * A `SELECT` query that acquires an MDL does not retrieve any data.
 
-

docs/reduction-in-locks.md

@@ -0,0 +1,75 @@
+# 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. These backups may be invalid and may fail at either the `backup` or the `--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 server remains under the backup lock. Now, you can execute more `DDL` operations concurrently while the backup is in progress. 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 phases.
+
+### Phase 1: `Operations performed without the lock`
+
+1. Copying all redo logs from checkpoint up to the current LSN and start following new entries.
+2. Starting the redo log thread.
+3. Tracking file operations from the redo log.
+4. Copying of all .ibd without taking any lock.
+5. Acquiring Lock Tables For Backup (LTFB)/Lock Instance For Backup (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.
+
+### Phase 2: `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.
+
+### Limitations
+
+1. The `ALTER INSTANCE ROTATE MASTER KEY` command should not be executed during [Phase 1](#phase-1-operations-performed-without-the-lock) if there are encrypted tables, as it will cause the backup to fail.
+
+2. The number of open file handles in your Operation System (OS) should be configured to match the number of files in the backup directory.
+
+3. When using the `--lock-ddl=REDUCED` option, backups can be larger in size. This happens because there are more operations allowed during backups.
+
+4. When the `DDL` operations that skip redo (for example, ADD INDEX) or change encryption types are executed while the backup is in progress, the `xtrabackup` can copy such tablespaces twice.
+
+### Benefits
+
+The `--lock-ddl=REDUCED` option key features are as follows:
+
+* Reduced locking: Rather than holding the backup lock throughout the entire backup process, it is only acquired for a very short period of time.
+
+* DDL statements: The server remains accessible for `DDL` operations during the backup process.
+
+* Consistency: Consistency is maintained by using the redo log to track file operations. During the backup process new metadata files are created to ensure consistency. In the `--prepare` phase, these metadata files are processed first to bring the database to a consistent state.
+
+

docs/xtrabackup-option-reference.md

@@ -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`
 
 
@@ -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 backup lock is disabled with the `--lock-ddl=OFF` option, a backup continues while concurrent DDL events are executed. These backups may be invalid and may fail at either the `backup` or the `--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
 

mkdocs-base.yml

@@ -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: