From f68f3d3faa4f692a1beb93e89b06393ef4379643 Mon Sep 17 00:00:00 2001 From: Alina Derkach Date: Thu, 30 Apr 2026 17:57:43 +0200 Subject: [PATCH 1/6] PXB-3757 Document --check-tables feature in 8.4 new file: docs/innodb-btree-check.md --- docs/innodb-btree-check.md | 167 +++++++++++++++++++++++++++++++++++++ 1 file changed, 167 insertions(+) create mode 100644 docs/innodb-btree-check.md diff --git a/docs/innodb-btree-check.md b/docs/innodb-btree-check.md new file mode 100644 index 00000000..d225dd71 --- /dev/null +++ b/docs/innodb-btree-check.md @@ -0,0 +1,167 @@ +# InnoDB B-tree validation during prepare + +The [`--check-tables`](./xtrabackup-option-reference.md#check-tables) option adds a structural validation step to the `--prepare` phase of Percona XtraBackup 8.4. It verifies the integrity of InnoDB B-tree indexes in a backup by detecting structural inconsistencies that are not covered by page-level checksums. + +Page checksums ensure that individual pages are not corrupted at the byte level. However, they do not verify whether those pages form a valid B-tree structure. As a result, structurally corrupted indexes can still pass checksum validation. + +`--check-tables` runs `btr_validate_index()` on every committed index in every `.ibd` tablespace. It detects issues such as broken sibling pointers, incorrect `PAGE_INDEX_ID` values, missing or incorrect min-record flags, parent-child pointer mismatches, all-zero pages, and inconsistent external LOB page references. + +The validation runs entirely during the `--prepare` phase, operates in read-only mode, and does not modify backup data. It can be executed in parallel using `--parallel` and integrates with `--apply-log-only` and `--export` workflows. + +By moving structural validation into the backup preparation stage, `--check-tables` allows corruption to be detected before a backup is promoted for production use. + +-------------------------------------------------------------------------------------------------------------- + +# InnoDB B-tree integrity validation during prepare + +Percona XtraBackup 8.4 introduces `--check-tables`, a new feature for the `--prepare` phase that validates InnoDB B-tree structures. Unlike standard checksums, this tool detects deep structural corruption—like broken links or mismatched pointers—without impacting the production database. By shifting discovery to the preparation stage, it prevents operators from deploying corrupted backups. + +## Backup and Prepare: A Quick Refresher + +Percona XtraBackup (PXB) is a hot, non-blocking backup tool for MySQL. A full backup proceeds in two logical phases. + +### Phase 1 — `--backup` + +PXB copies InnoDB data files while the server keeps running. Because the server continues writing during the copy, PXB also streams the redo log generated during the backup window. The result is a snapshot of data files plus redo entries that bring them forward to a consistent point. + +By itself, this snapshot is not immediately restorable: pages may reflect partially applied changes, and the backup represents a mixture of committed and in-flight transactions. + +### Phase 2 — `--prepare` + +PXB replays the captured redo log against the copied data files. This is equivalent to InnoDB crash recovery: + +- Redo is applied to bring pages forward +- Uncommitted transactions are rolled back (if needed) + +After prepare, the backup becomes crash-consistent and can be safely restored. + +A useful mental model: the backup is a photograph plus a journal; prepare replays the journal to make the photograph coherent. + +## The Problem: Why Checksums Are Not Enough + +PXB already verifies page checksums during `--backup`. These checks detect physical corruption such as torn pages or bit-level damage. + +However, a page checksum only answers whether a page is intact at the byte level. It does not validate whether the **B-tree structure formed by those pages is correct**. + +As a result, structural corruption can pass checksum validation, including: + +- Broken sibling links in B-tree pages +- Incorrect `PAGE_INDEX_ID` assignments +- Missing or misplaced minimum-record flags +- Invalid parent-child pointer relationships +- External LOB pages shared between multiple records +- All-zero pages that still produce valid checksums + +These issues produce backups that are internally consistent at the byte level but logically corrupted at the index level. + +Worse, redo application during `--prepare` faithfully preserves any pre-existing structural corruption in the source. + +## The Solution: `--check-tables` + +`--check-tables` extends the `--prepare` phase by validating the structural integrity of every InnoDB B-tree index in the backup. + +It runs `btr_validate_index()` over all committed indexes in all tablespaces and detects: + +- Broken sibling links +- Incorrect `PAGE_INDEX_ID` +- Missing or incorrect min-record flags +- Parent-child pointer mismatches +- All-zero pages +- Shared or inconsistent external LOB pages + +The validation is: + +- **Read-only** +- **Parallel (scales with `--parallel`)** +- **Compatible with incremental prepare and export** +- **Non-intrusive to production workloads** + +It shifts corruption detection from post-deployment validation to the backup preparation stage. + +## Output + +A successful run ends with: + + +## Benefits + +The `--check-tables` option provides the following benefits: + +* Detects structural index corruption that is not visible to page checksum validation +* Validates B-tree consistency across all InnoDB indexes in the backup +* Runs entirely on backup data with no impact on the production server +* Supports parallel execution using `--parallel` for scalable validation +* Integrates with incremental and export workflows during `--prepare` + +## Limitations + +* Validation is performed only during the `--prepare` phase +* Increased CPU and I/O usage on the backup host during validation +* Runtime depends on number of tablespaces and indexes in the backup +* Does not replace logical validation tools such as `CHECK TABLE` on a live server + +## How it works + +During `--prepare`, after redo log application completes, XtraBackup performs structural validation of InnoDB indexes. + +For each tablespace: + +1. Loads index metadata from the backup +2. Iterates through all committed indexes +3. Executes `btr_validate_index()` on each index tree +4. Validates structural relationships between pages and records +5. Reports any detected inconsistencies + +The validation is read-only and does not modify pages or metadata in the backup. + +## Parallel execution + +Validation is parallelized using the existing `--parallel` infrastructure in XtraBackup. + +Each worker thread processes independent tablespaces: + +- Retrieves a tablespace from a shared iterator +- Loads index definitions from SDI data +- Validates each index using `btr_validate_index()` +- Reports errors independently of other threads + +Validation is not fail-fast; all workers continue processing to produce a complete report of detected corruption. + +## Usage + +Final prepare step: + +```bash +xtrabackup --prepare --check-tables \ + --target-dir=/backups/full \ + --parallel=8 +``` + +Incremental prepare: + +```bash +xtrabackup --prepare --apply-log-only --check-tables \ + --target-dir=/backups/full \ + --incremental-dir=/backups/inc1 \ + --parallel=8 +``` + +## Output + +A successful run ends with: + +```text +All table checks passed +``` + +If corruption is detected: + +```text +Table check failed. The backup may be corrupted. +``` + +The process returns a non-zero exit code and logs detailed information about each detected issue. + +## Summary + +`--check-tables` extends the `--prepare` phase with structural validation of InnoDB B-tree indexes. It complements page checksum verification by detecting inconsistencies in index structure, enabling earlier detection of backup corruption before deployment to production systems. From 95af2d03dfe74e18a891cfa83c0db6769507d321 Mon Sep 17 00:00:00 2001 From: Alina Derkach Date: Thu, 14 May 2026 18:10:29 +0200 Subject: [PATCH 2/6] PXB-3757 Document --check-tables feature in 8.4 modified: docs/innodb-btree-check.md modified: docs/xtrabackup-option-reference.md --- docs/innodb-btree-check.md | 184 ++++++++++++++-------------- docs/xtrabackup-option-reference.md | 16 +++ mkdocs-base.yml | 1 + 3 files changed, 109 insertions(+), 92 deletions(-) diff --git a/docs/innodb-btree-check.md b/docs/innodb-btree-check.md index d225dd71..aa13428c 100644 --- a/docs/innodb-btree-check.md +++ b/docs/innodb-btree-check.md @@ -1,167 +1,167 @@ -# InnoDB B-tree validation during prepare - -The [`--check-tables`](./xtrabackup-option-reference.md#check-tables) option adds a structural validation step to the `--prepare` phase of Percona XtraBackup 8.4. It verifies the integrity of InnoDB B-tree indexes in a backup by detecting structural inconsistencies that are not covered by page-level checksums. +# InnoDB B-tree integrity validation during prepare -Page checksums ensure that individual pages are not corrupted at the byte level. However, they do not verify whether those pages form a valid B-tree structure. As a result, structurally corrupted indexes can still pass checksum validation. +## Overview -`--check-tables` runs `btr_validate_index()` on every committed index in every `.ibd` tablespace. It detects issues such as broken sibling pointers, incorrect `PAGE_INDEX_ID` values, missing or incorrect min-record flags, parent-child pointer mismatches, all-zero pages, and inconsistent external LOB page references. +Percona XtraBackup 8.4.0-6 introduces the [`--check-tables`](xtrabackup-option-reference.md#check-tables) option that validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. -The validation runs entirely during the `--prepare` phase, operates in read-only mode, and does not modify backup data. It can be executed in parallel using `--parallel` and integrates with `--apply-log-only` and `--export` workflows. +The `--check-tables` option runs `btr_validate_index()` on every committed index in each `.ibd` tablespace and detects structural inconsistencies not covered by page checksum verification. -By moving structural validation into the backup preparation stage, `--check-tables` allows corruption to be detected before a backup is promoted for production use. +The validation process: --------------------------------------------------------------------------------------------------------------- +* Runs during `--prepare` -# InnoDB B-tree integrity validation during prepare +* Operates in read-only mode -Percona XtraBackup 8.4 introduces `--check-tables`, a new feature for the `--prepare` phase that validates InnoDB B-tree structures. Unlike standard checksums, this tool detects deep structural corruption—like broken links or mismatched pointers—without impacting the production database. By shifting discovery to the preparation stage, it prevents operators from deploying corrupted backups. +* Does not modify backup contents -## Backup and Prepare: A Quick Refresher +* Supports parallel execution through `--parallel` -Percona XtraBackup (PXB) is a hot, non-blocking backup tool for MySQL. A full backup proceeds in two logical phases. +* Supports workflows that use `--apply-log-only` -### Phase 1 — `--backup` +* Supports transportable tablespace export with `--export` -PXB copies InnoDB data files while the server keeps running. Because the server continues writing during the copy, PXB also streams the redo log generated during the backup window. The result is a snapshot of data files plus redo entries that bring them forward to a consistent point. +Validation during `--prepare` helps detect corrupted indexes before backup restore or production deployment. -By itself, this snapshot is not immediately restorable: pages may reflect partially applied changes, and the backup represents a mixture of committed and in-flight transactions. +## Why checksum validation is not enough -### Phase 2 — `--prepare` +Percona XtraBackup verifies page checksums during `--backup`. Checksum validation detects physical page corruption, including: -PXB replays the captured redo log against the copied data files. This is equivalent to InnoDB crash recovery: +* Torn pages -- Redo is applied to bring pages forward -- Uncommitted transactions are rolled back (if needed) +* Storage bit rot -After prepare, the backup becomes crash-consistent and can be safely restored. +* Corrupted transfers -A useful mental model: the backup is a photograph plus a journal; prepare replays the journal to make the photograph coherent. +* Filesystem-level damage -## The Problem: Why Checksums Are Not Enough +Checksum validation confirms page integrity at the byte level. B-tree structure validation requires additional checks across related pages. -PXB already verifies page checksums during `--backup`. These checks detect physical corruption such as torn pages or bit-level damage. +Structural corruption that can pass checksum validation includes: -However, a page checksum only answers whether a page is intact at the byte level. It does not validate whether the **B-tree structure formed by those pages is correct**. +* Broken sibling page links -As a result, structural corruption can pass checksum validation, including: +* Incorrect `PAGE_INDEX_ID` assignments -- Broken sibling links in B-tree pages -- Incorrect `PAGE_INDEX_ID` assignments -- Missing or misplaced minimum-record flags -- Invalid parent-child pointer relationships -- External LOB pages shared between multiple records -- All-zero pages that still produce valid checksums +* Missing or misplaced minimum-record flags -These issues produce backups that are internally consistent at the byte level but logically corrupted at the index level. +* Invalid parent-to-child page references -Worse, redo application during `--prepare` faithfully preserves any pre-existing structural corruption in the source. +* Shared external LOB (large object) pages -## The Solution: `--check-tables` +* All-zero pages with valid checksums -`--check-tables` extends the `--prepare` phase by validating the structural integrity of every InnoDB B-tree index in the backup. +Applying the redo log during `--prepare` copies the existing structural corruption from the source server into the prepared backup. As a result, backups can remain physically consistent while containing logically corrupted indexes. -It runs `btr_validate_index()` over all committed indexes in all tablespaces and detects: +## How `--check-tables` works -- Broken sibling links -- Incorrect `PAGE_INDEX_ID` -- Missing or incorrect min-record flags -- Parent-child pointer mismatches -- All-zero pages -- Shared or inconsistent external LOB pages +After applying the redo log during the `--prepare` phase, Percona XtraBackup validates InnoDB index structures in the backup. -The validation is: +The validation process runs in read-only mode against backup files and does not modify backup contents. -- **Read-only** -- **Parallel (scales with `--parallel`)** -- **Compatible with incremental prepare and export** -- **Non-intrusive to production workloads** +For each tablespace, Percona XtraBackup: -It shifts corruption detection from post-deployment validation to the backup preparation stage. +1. Loads index metadata -## Output +2. Identifies committed indexes -A successful run ends with: +3. Executes `btr_validate_index()` on each index +4. Traverses B-tree pages and validates structural relationships -## Benefits +5. Reports detected inconsistencies -The `--check-tables` option provides the following benefits: +The validation process verifies: -* Detects structural index corruption that is not visible to page checksum validation -* Validates B-tree consistency across all InnoDB indexes in the backup -* Runs entirely on backup data with no impact on the production server -* Supports parallel execution using `--parallel` for scalable validation -* Integrates with incremental and export workflows during `--prepare` +* Sibling page relationships -## Limitations +* Parent-to-child page references -* Validation is performed only during the `--prepare` phase -* Increased CPU and I/O usage on the backup host during validation -* Runtime depends on number of tablespaces and indexes in the backup -* Does not replace logical validation tools such as `CHECK TABLE` on a live server +* Page ownership metadata -## How it works +* Minimum-record markers -During `--prepare`, after redo log application completes, XtraBackup performs structural validation of InnoDB indexes. +* External LOB (large object) page ownership -For each tablespace: +If the validator detects corruption, validation continues for the remaining indexes and tablespaces to produce a complete report. -1. Loads index metadata from the backup -2. Iterates through all committed indexes -3. Executes `btr_validate_index()` on each index tree -4. Validates structural relationships between pages and records -5. Reports any detected inconsistencies +## Validation checks -The validation is read-only and does not modify pages or metadata in the backup. +| Check | Detected condition | +|------|---------------------| +| Broken sibling links | Invalid sibling or parent navigation pointers | +| `PAGE_INDEX_ID` mismatches | Page index ID does not match index metadata | +| Minimum-record flag validation | Minimum-record flag is missing or invalid | +| Parent-child pointer validation | Child page boundaries do not match parent node structure | +| External LOB validation | Shared, freed, or out-of-bounds LOB page references | +| All-zero page detection | Page contains only zero bytes | ## Parallel execution -Validation is parallelized using the existing `--parallel` infrastructure in XtraBackup. +The `--check-tables` option uses the existing `--parallel` infrastructure in Percona XtraBackup. Worker threads process tablespaces independently. + +Each worker thread: -Each worker thread processes independent tablespaces: +1. Retrieves a tablespace from the shared queue + +2. Loads metadata for the tablespace + +3. Validates committed indexes + +4. Reports validation results + +## Limitations -- Retrieves a tablespace from a shared iterator -- Loads index definitions from SDI data -- Validates each index using `btr_validate_index()` -- Reports errors independently of other threads +The `--check-tables` option has the following limitations: -Validation is not fail-fast; all workers continue processing to produce a complete report of detected corruption. +* Validation runs only during `--prepare` + +* Validation increases CPU and I/O usage on the backup host + +* Runtime depends on the number of tablespaces and indexes + +* Validation does not replace logical consistency checks such as `CHECK TABLE` ## Usage -Final prepare step: +`--check-tables` is valid only with `--prepare`. + +### Validate a full backup ```bash xtrabackup --prepare --check-tables \ - --target-dir=/backups/full \ - --parallel=8 + --target-dir=/backups/full \ + --parallel=8 ``` -Incremental prepare: +### Validate an incremental backup chain ```bash xtrabackup --prepare --apply-log-only --check-tables \ - --target-dir=/backups/full \ - --incremental-dir=/backups/inc1 \ - --parallel=8 + --target-dir=/backups/full \ + --incremental-dir=/backups/inc1 \ + --parallel=8 +``` + +### Validate and export tablespaces + +```bash +xtrabackup --prepare --export --check-tables \ + --target-dir=/backups/full \ + --parallel=8 ``` ## Output -A successful run ends with: +A successful validation operation ends with: ```text All table checks passed ``` -If corruption is detected: +A failed validation operation returns a non-zero exit code and logs the following message: ```text Table check failed. The backup may be corrupted. ``` -The process returns a non-zero exit code and logs detailed information about each detected issue. - -## Summary - -`--check-tables` extends the `--prepare` phase with structural validation of InnoDB B-tree indexes. It complements page checksum verification by detecting inconsistencies in index structure, enabling earlier detection of backup corruption before deployment to production systems. +The log contains detailed information for each detected inconsistency. \ No newline at end of file diff --git a/docs/xtrabackup-option-reference.md b/docs/xtrabackup-option-reference.md index 22cd1466..7a408d45 100644 --- a/docs/xtrabackup-option-reference.md +++ b/docs/xtrabackup-option-reference.md @@ -110,6 +110,22 @@ If a privilege is not needed for the current operation but is missing and may be xtrabackup: Warning: missing required privilege REPLICATION CLIENT on *.* ``` +### check-tables + +Usage: `--check-tables` + +Introduced in Percona XtraBackup 8.4.0-6. + +Enables InnoDB B-tree structural validation during the `--prepare` phase after redo log application completes. + +The option runs `btr_validate_index()` on every committed index in each `.ibd` tablespace in the backup. Validation detects structural inconsistencies that page checksum verification does not detect, such as broken B-tree relationships, invalid page metadata, and inconsistent external LOB references. + +The validation process runs in read-only mode and does not modify backup data. The operation integrates with `--apply-log-only`, `--parallel`, and `--export`. + +If validation detects corruption, xtrabackup reports the issue and returns a non-zero exit code after completing all checks. + +Find more information in the [InnoDB B-tree integrity validation during prepare](innodb-btree-check.md) document. + ### close-files Usage: `--close-files` diff --git a/mkdocs-base.yml b/mkdocs-base.yml index 22338f53..fad7a8a0 100644 --- a/mkdocs-base.yml +++ b/mkdocs-base.yml @@ -206,6 +206,7 @@ nav: - flush-tables-with-read-lock.md + - innodb-btree-check.md - log-enhancements.md - redo-log-archiving.md - reduction-in-locks.md From 1ce07318f074e186d07010ad8b8959984e463e76 Mon Sep 17 00:00:00 2001 From: Alina Derkach Date: Fri, 15 May 2026 19:05:56 +0200 Subject: [PATCH 3/6] Apply the part of changes after review --- docs/innodb-btree-check.md | 102 +++++++++++++++++++++++++++---------- 1 file changed, 74 insertions(+), 28 deletions(-) diff --git a/docs/innodb-btree-check.md b/docs/innodb-btree-check.md index aa13428c..b9f396a0 100644 --- a/docs/innodb-btree-check.md +++ b/docs/innodb-btree-check.md @@ -2,25 +2,7 @@ ## Overview -Percona XtraBackup 8.4.0-6 introduces the [`--check-tables`](xtrabackup-option-reference.md#check-tables) option that validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. - -The `--check-tables` option runs `btr_validate_index()` on every committed index in each `.ibd` tablespace and detects structural inconsistencies not covered by page checksum verification. - -The validation process: - -* Runs during `--prepare` - -* Operates in read-only mode - -* Does not modify backup contents - -* Supports parallel execution through `--parallel` - -* Supports workflows that use `--apply-log-only` - -* Supports transportable tablespace export with `--export` - -Validation during `--prepare` helps detect corrupted indexes before backup restore or production deployment. +Percona XtraBackup 8.4.0-6 introduces the [`--check-tables`](xtrabackup-option-reference.md#check-tables) option that validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. Validation during `--prepare` helps detect corrupted indexes before backup restore or production deployment. ## Why checksum validation is not enough @@ -54,9 +36,17 @@ Applying the redo log during `--prepare` copies the existing structural corrupti ## How `--check-tables` works -After applying the redo log during the `--prepare` phase, Percona XtraBackup validates InnoDB index structures in the backup. +The `--check-tables` option executes `btr_validate_index()` on every committed index in each `.ibd` tablespace using the number of threads specified by [`--parallel`](xtrabackup-option-reference.md#parallel). `--check-tables` detects structural inconsistencies that page checksum verification cannot detect. This option applies only to InnoDB tables. -The validation process runs in read-only mode against backup files and does not modify backup contents. +Validation runs during the `--prepare` phase after applying the redo log. The process operates in read-only mode against backup files and does not modify backup contents. Validation continues even after detecting corrupted tables, allowing all problematic tables and indexes to be reported in a single run. + +The option supports: + +* [Parallel execution](#parallel-execution) through [`--parallel`](xtrabackup-option-reference.md#parallel) + +* Workflows that use [`--apply-log-only`](xtrabackup-option-reference.md#apply-log-only) + +* Transportable tablespace export with [`--export`](xtrabackup-option-reference.md#export). For each tablespace, Percona XtraBackup: @@ -82,9 +72,13 @@ The validation process verifies: * External LOB (large object) page ownership -If the validator detects corruption, validation continues for the remaining indexes and tablespaces to produce a complete report. +### Offloading `CHECK TABLE` -## Validation checks +This option is functionally equivalent to running `CHECK TABLE` on InnoDB tables, but it executes on the backup during the `--prepare` phase instead of on a running production server. + +This allows a significant portion of `CHECK TABLE` workload to be offloaded from production systems to an offline environment where the backup is prepared and validated. + +### Detected corruption conditions | Check | Detected condition | |------|---------------------| @@ -95,7 +89,7 @@ If the validator detects corruption, validation continues for the remaining inde | External LOB validation | Shared, freed, or out-of-bounds LOB page references | | All-zero page detection | Page contains only zero bytes | -## Parallel execution +### Parallel execution The `--check-tables` option uses the existing `--parallel` infrastructure in Percona XtraBackup. Worker threads process tablespaces independently. @@ -109,7 +103,7 @@ Each worker thread: 4. Reports validation results -## Limitations +### Limitations The `--check-tables` option has the following limitations: @@ -123,8 +117,6 @@ The `--check-tables` option has the following limitations: ## Usage -`--check-tables` is valid only with `--prepare`. - ### Validate a full backup ```bash @@ -164,4 +156,58 @@ A failed validation operation returns a non-zero exit code and logs the followin Table check failed. The backup may be corrupted. ``` -The log contains detailed information for each detected inconsistency. \ No newline at end of file +The log contains detailed information for each detected inconsistency. + +### Corruption examples + +1. Sibling page relationships corruption. + + ??? example "Expected output" + + ```{.text .no-copy} + 2026-05-15T13:42:20.270268+01:00 2 [ERROR] [MY-013051] [InnoDB] + In pages [page id: space=2, page number=5] + and [page id: space=2, page number=6] + of index PRIMARY of table test.t1 + + InnoDB: broken FIL_PAGE_NEXT or FIL_PAGE_PREV links + ``` + +2. Parent-to-child page references corruption. + + ??? example "Expected output" + + ```{.text .no-copy} + 2026-05-15T13:38:12.343921+01:00 2 [ERROR] [MY-011825] [InnoDB] + B-tree corruption: page 0 is empty but is not the root page + in index PRIMARY. Possible all-zero (unflushed) page. + ``` + +3. Page ownership metadata corruption. + + ??? example "Expected output" + + ```{.text .no-copy} + 2026-05-15T13:38:12.343894+01:00 2 [ERROR] [MY-011866] [InnoDB] + Page index id 0 != data dictionary index id 204 + ``` + +4. Minimum-record markers corruption. + + ??? example "Expected output" + + ```{.text .no-copy} + 2026-05-15T13:42:27.237530+01:00 2 [ERROR] [MY-014011] [InnoDB] + Minimum record flag is wrongly set to rec on page '4' + at level '0' for index 'PRIMARY' of table 'sys/sys_config'. + ``` + +5. External LOB page ownership corruption. + + ??? example "Expected output" + + ```{.text .no-copy} + 2026-05-15T13:42:34.475996+01:00 2 [ERROR] [MY-011825] [InnoDB] Invalid record! External LOB first page cannot be shared between two records + 2026-05-15T13:42:34.476009+01:00 2 [ERROR] [MY-011825] [InnoDB] The external LOB first page is [page id: space=4294967294, page number=1002] + 2026-05-15T13:42:34.476014+01:00 2 [ERROR] [MY-011825] [InnoDB] The first occurrence of the external LOB first page is in record : page_no: 992 with heap_no: 4 + ``` From 6f08b2021782f9ac5f4ffbcb85f72a5e3cf51fae Mon Sep 17 00:00:00 2001 From: Alina Derkach Date: Mon, 18 May 2026 17:20:21 +0200 Subject: [PATCH 4/6] Apply the changes to resolve the comments --- docs/innodb-btree-check.md | 86 ++++++++++++++++++++++------- docs/xtrabackup-option-reference.md | 8 +-- 2 files changed, 71 insertions(+), 23 deletions(-) diff --git a/docs/innodb-btree-check.md b/docs/innodb-btree-check.md index b9f396a0..9d33c015 100644 --- a/docs/innodb-btree-check.md +++ b/docs/innodb-btree-check.md @@ -2,23 +2,43 @@ ## Overview -Percona XtraBackup 8.4.0-6 introduces the [`--check-tables`](xtrabackup-option-reference.md#check-tables) option that validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. Validation during `--prepare` helps detect corrupted indexes before backup restore or production deployment. +Percona XtraBackup 8.4.0-6 introduces the [`--check-tables`](xtrabackup-option-reference.md#check-tables) option that validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. Validation during `--prepare` helps detect corrupted indexes before restore or production deployment. ## Why checksum validation is not enough -Percona XtraBackup verifies page checksums during `--backup`. Checksum validation detects physical page corruption, including: +Percona XtraBackup verifies InnoDB page checksums during `--backup`. These checks ensure that the backup contains checksum-valid pages at backup time. + +Checksum validation detects physical corruption within individual pages, including: * Torn pages -* Storage bit rot +* Corrupted writes + +* Transfer corruption + +* Some storage or filesystem-level corruption + +When the server modifies a page while XtraBackup copies it, XtraBackup retries the copy until the checksum becomes consistent. The retry process prevents partially modified pages from entering the backup. + +A successful backup therefore guarantees checksum-valid pages, but checksum validation alone cannot guarantee a fully valid restore. + +### Corruption can happen after backup creation -* Corrupted transfers +A backup can become corrupted after creation because of storage or filesystem issues. -* Filesystem-level damage +During `--prepare`, XtraBackup only re-validates pages involved in redo application. Pages outside redo processing may never undergo another checksum check. -Checksum validation confirms page integrity at the byte level. B-tree structure validation requires additional checks across related pages. +For this reason, running `CHECK TABLE` after restore remains a recommended practice. `CHECK TABLE` forces page reads and validates both checksums and structural consistency. -Structural corruption that can pass checksum validation includes: +### Checksums do not verify page relationships + +Checksum validation only confirms that the bytes within a page match the checksum stored in the page header. + +XtraBackup does not validate B-tree structure or relationships between pages during backup. As a result, structurally corrupted pages can still enter the backup if those pages remain checksum-valid on the source server. + +Structural corruption rarely occurs and usually results from server bugs, backup tool bugs, storage failures, or filesystem-level corruption. + +Structural corruption can include: * Broken sibling page links @@ -32,13 +52,11 @@ Structural corruption that can pass checksum validation includes: * All-zero pages with valid checksums -Applying the redo log during `--prepare` copies the existing structural corruption from the source server into the prepared backup. As a result, backups can remain physically consistent while containing logically corrupted indexes. - ## How `--check-tables` works -The `--check-tables` option executes `btr_validate_index()` on every committed index in each `.ibd` tablespace using the number of threads specified by [`--parallel`](xtrabackup-option-reference.md#parallel). `--check-tables` detects structural inconsistencies that page checksum verification cannot detect. This option applies only to InnoDB tables. +The `--check-tables` option executes `btr_validate_index()` on every committed index in each `.ibd` tablespace using the number of threads specified by [`--parallel`](xtrabackup-option-reference.md#parallel). `--check-tables` detects structural inconsistencies that page checksum verification cannot detect. The option applies only to InnoDB tables. -Validation runs during the `--prepare` phase after applying the redo log. The process operates in read-only mode against backup files and does not modify backup contents. Validation continues even after detecting corrupted tables, allowing all problematic tables and indexes to be reported in a single run. +Percona XtraBackup runs validation during the `--prepare` phase after applying the redo log. The validation process operates in read-only mode against backup files and does not modify backup contents. Validation continues after detecting corruption so that Percona XtraBackup can report all problematic tables and indexes in a single run. The option supports: @@ -46,7 +64,7 @@ The option supports: * Workflows that use [`--apply-log-only`](xtrabackup-option-reference.md#apply-log-only) -* Transportable tablespace export with [`--export`](xtrabackup-option-reference.md#export). +* Transportable tablespace export with [`--export`](xtrabackup-option-reference.md#export) For each tablespace, Percona XtraBackup: @@ -74,15 +92,25 @@ The validation process verifies: ### Offloading `CHECK TABLE` -This option is functionally equivalent to running `CHECK TABLE` on InnoDB tables, but it executes on the backup during the `--prepare` phase instead of on a running production server. +The `--check-tables` option provides functionality similar to `CHECK TABLE` for InnoDB tables, but Percona XtraBackup performs validation on backup files during the `--prepare` phase instead of on a running production server. -This allows a significant portion of `CHECK TABLE` workload to be offloaded from production systems to an offline environment where the backup is prepared and validated. +Validation during `--prepare` moves structural integrity verification from restored database instances to the backup preparation workflow. A backup or staging host can run validation without starting MySQL on the restored backup. + +Using `--check-tables` during `--prepare` provides the following operational benefits: + +* Eliminates the need to start a MySQL server on restored backups solely for structural validation + +* Moves validation workload away from running production systems + +* Detects structural corruption earlier in the backup validation workflow + +* Detects corruption before restore or deployment ### Detected corruption conditions | Check | Detected condition | |------|---------------------| -| Broken sibling links | Invalid sibling or parent navigation pointers | +| Broken sibling links | Invalid sibling-page or parent-page navigation pointers | | `PAGE_INDEX_ID` mismatches | Page index ID does not match index metadata | | Minimum-record flag validation | Minimum-record flag is missing or invalid | | Parent-child pointer validation | Child page boundaries do not match parent node structure | @@ -91,7 +119,7 @@ This allows a significant portion of `CHECK TABLE` workload to be offloaded from ### Parallel execution -The `--check-tables` option uses the existing `--parallel` infrastructure in Percona XtraBackup. Worker threads process tablespaces independently. +The `--check-tables` option uses the existing `--parallel` infrastructure from Percona XtraBackup. Worker threads process tablespaces independently. Each worker thread: @@ -113,10 +141,14 @@ The `--check-tables` option has the following limitations: * Runtime depends on the number of tablespaces and indexes +* For incremental backup chains, run `--check-tables` only during the final prepare stage because the option verifies all tables and indexes each time it runs + * Validation does not replace logical consistency checks such as `CHECK TABLE` ## Usage +The `--check-tables` option uses the thread count specified by `--parallel`. Start with `--parallel=8` and tune the value according to available CPU and disk I/O capacity on the backup host. + ### Validate a full backup ```bash @@ -147,13 +179,29 @@ xtrabackup --prepare --export --check-tables \ A successful validation operation ends with: ```text -All table checks passed +2026-05-15T15:41:57.808327+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/replication_group_member_actions +2026-05-15T15:41:57.808630+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/replication_group_configuration_version +2026-05-15T15:41:57.808810+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/server_cost +2026-05-15T15:41:57.808998+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/engine_cost +2026-05-15T15:41:57.809190+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/proxies_priv +2026-05-15T15:41:57.809511+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/ndb_binlog_index +2026-05-15T15:41:58.051499+01:00 0 [Note] [MY-011825] [Xtrabackup] All table checks passed. +``` + +A failed validation operation returns a non-zero exit code. During validation, XtraBackup logs each table as it processes it: + +```text +2026-05-15T13:42:23.691691+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: test/t1 +2026-05-15T13:42:23.697349+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: test/t_lob +2026-05-15T13:42:23.782555+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/dd_properties +2026-05-15T13:42:23.782835+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/innodb_dynamic_metadata +... ``` -A failed validation operation returns a non-zero exit code and logs the following message: +If validation detects corruption, XtraBackup reports the affected tables and ends with the following summary message: ```text -Table check failed. The backup may be corrupted. +2026-05-15T13:42:24.670469+01:00 0 [ERROR] [MY-011825] [Xtrabackup] Table check failed. The backup may be corrupted. ``` The log contains detailed information for each detected inconsistency. diff --git a/docs/xtrabackup-option-reference.md b/docs/xtrabackup-option-reference.md index 7a408d45..b28cf40d 100644 --- a/docs/xtrabackup-option-reference.md +++ b/docs/xtrabackup-option-reference.md @@ -118,13 +118,13 @@ Introduced in Percona XtraBackup 8.4.0-6. Enables InnoDB B-tree structural validation during the `--prepare` phase after redo log application completes. -The option runs `btr_validate_index()` on every committed index in each `.ibd` tablespace in the backup. Validation detects structural inconsistencies that page checksum verification does not detect, such as broken B-tree relationships, invalid page metadata, and inconsistent external LOB references. +The option runs `btr_validate_index()` on every committed index in each `.ibd` tablespace in the backup. Validation detects structural inconsistencies that page checksum verification cannot detect, including broken B-tree relationships, invalid page metadata, and inconsistent external LOB references. -The validation process runs in read-only mode and does not modify backup data. The operation integrates with `--apply-log-only`, `--parallel`, and `--export`. +Percona XtraBackup runs validation in read-only mode and does not modify backup data. The option supports `--apply-log-only`, `--parallel`, and `--export`. -If validation detects corruption, xtrabackup reports the issue and returns a non-zero exit code after completing all checks. +If validation detects corruption, xtrabackup reports the affected tables and returns a non-zero exit code after completing all checks. -Find more information in the [InnoDB B-tree integrity validation during prepare](innodb-btree-check.md) document. +For more information, see [InnoDB B-tree integrity validation during prepare](innodb-btree-check.md). ### close-files From fee5c8a83f44aa8ad8594744935680fa836f08cf Mon Sep 17 00:00:00 2001 From: Alina Derkach Date: Mon, 18 May 2026 18:29:24 +0200 Subject: [PATCH 5/6] Adding references to the table and fixing links --- docs/about-xtrabackup.md | 2 +- docs/backup-strategy.md | 2 +- docs/glossary.md | 2 +- docs/how-xtrabackup-works.md | 2 +- docs/index.md | 2 +- docs/innodb-btree-check.md | 79 ++++++++++++------------------ docs/release-notes/8.4.0-1.md | 9 ++-- docs/release-notes/8.4.0-2.md | 2 +- docs/release-notes/8.4.0-3.md | 2 +- docs/xtrabackup-binary-overview.md | 2 +- docs/yum-repo.md | 4 +- mkdocs-base.yml | 7 +-- 12 files changed, 46 insertions(+), 69 deletions(-) diff --git a/docs/about-xtrabackup.md b/docs/about-xtrabackup.md index c4b5c26a..d0a4484f 100644 --- a/docs/about-xtrabackup.md +++ b/docs/about-xtrabackup.md @@ -24,7 +24,7 @@ With Percona XtraBackup you can: ## Support -Percona’s enterprise-grade commercial [MySQL Support :octicons-link-external-16:](http://www.percona.com/mysql-support/) contracts include support for Percona XtraBackup. We recommend support for critical production deployments. +Percona’s enterprise-grade commercial [MySQL Support :octicons-link-external-16:](https://www.percona.com/services/expert-support/) contracts include support for Percona XtraBackup. We recommend support for critical production deployments. ## Supported storage engines diff --git a/docs/backup-strategy.md b/docs/backup-strategy.md index f6dbf60c..62736038 100644 --- a/docs/backup-strategy.md +++ b/docs/backup-strategy.md @@ -91,7 +91,7 @@ You must test the effectiveness of your backups and demonstrate that you can rec |--------|---------| | Perform Regular Test Restores | The most reliable way to test backups is to periodically restore the data to a separate system. This verifies the backup's integrity and the restoration process's functionality. | | Monitor Backup Reports | Regularly review backup reports and logs for any errors or failures during the backup process. This can help identify issues early before they become critical problems. | -| Check for Data Consistency | Compare the original data with the backed-up data to ensure consistency. This can be done by checking file sizes, using checksums, or employing other data validation techniques. You can use [pt-table-checksum](https://docs.percona.com/percona-toolkit/latest/pt-table-checksum.html) from Percona Toolkit. | +| Check for Data Consistency | Compare the original data with the backed-up data to ensure consistency. This can be done by checking file sizes, using checksums, or employing other data validation techniques. You can use [pt-table-checksum](https://docs.percona.com/percona-toolkit/pt-table-checksum.html) from Percona Toolkit. | | Simulate Disaster Scenarios | Conducting a simulated disaster recovery exercise can help determine how well your backup system will perform under stress and identify any gaps in your recovery plan. | | Audit Backup Procedures | Regular audits of the backup procedures can ensure that the backups are being performed in accordance with the established policies and that the backup system is functioning as expected. | | Validate Backup Configuration | Ensure that the backup configuration is correct and that all necessary data is being backed up. This includes checking backup schedules, retention policies, and the scope of the data backed up. | diff --git a/docs/glossary.md b/docs/glossary.md index b75e8194..653522a5 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -186,7 +186,7 @@ To support simultaneous compression and streaming, Percona XtraBackup uses the x ## XtraDB -Percona XtraDB is an enhanced version of the InnoDB storage engine, designed to better scale on modern hardware. Percona XtraDB includes features which are useful in a high performance environment. It is fully backward-compatible, and is a drop-in replacement for the standard InnoDB storage engine. For more information, see [The Percona XtraDB Storage Engine :octicons-link-external-16:](https://www.percona.com/doc/percona-server/innovation-release/percona-xtradb.html). +Percona XtraDB is an enhanced version of the InnoDB storage engine, designed to better scale on modern hardware. Percona XtraDB includes features which are useful in a high performance environment. It is fully backward-compatible, and is a drop-in replacement for the standard InnoDB storage engine. For more information, see [The Percona XtraDB Storage Engine :octicons-link-external-16:](https://docs.percona.com/percona-server/8.4/percona-xtradb.html). ## Zstandard (ZSTD) diff --git a/docs/how-xtrabackup-works.md b/docs/how-xtrabackup-works.md index aa2250fd..51d1ccfe 100644 --- a/docs/how-xtrabackup-works.md +++ b/docs/how-xtrabackup-works.md @@ -16,7 +16,7 @@ The `--register-redo-log-consumer` parameter is disabled by default. When enable Percona XtraBackup remembers the LSN when it starts, and then copies the data files. The operation takes time, and the files may change, then LSN reflects the state of the database at different points in time. Percona XtraBackup also runs a background process that watches the transaction log files, and copies any changes. Percona XtraBackup does this continually. The transaction logs are written in a round-robin fashion, and can be reused. -Percona XtraBackup uses [Backup locks :octicons-link-external-16:](https://docs.percona.com/percona-server/innovation-release/backup-locks.html) where available as a lightweight alternative to `FLUSH TABLES WITH READ LOCK`. MySQL {{vers}} allows acquiring an instance level backup lock via the `LOCK INSTANCE FOR BACKUP` statement. +Percona XtraBackup uses [Backup locks :octicons-link-external-16:](https://docs.percona.com/percona-server/8.4/backup-locks.html) where available as a lightweight alternative to `FLUSH TABLES WITH READ LOCK`. MySQL {{vers}} allows acquiring an instance level backup lock via the `LOCK INSTANCE FOR BACKUP` statement. Locking is only done for MyISAM and other non-InnoDB tables after Percona XtraBackup finishes backing up all InnoDB/XtraDB data and diff --git a/docs/index.md b/docs/index.md index d282958f..465f1634 100644 --- a/docs/index.md +++ b/docs/index.md @@ -8,7 +8,7 @@ Percona XtraBackup is an open source hot backup utility for MySQL-based servers that keep your database fully available during planned maintenance windows. Whether it is a 24x7 highly loaded server or a low-transaction-volume -Percona XtraBackup is designed to make backups seamless without disrupting the performance of the server in a production environment. Percona XtraBackup (PXB) is a 100% open source backup solution with [commercial support :octicons-link-external-16:](https://www.percona.com/mysql-support/) available for organizations who want to benefit from comprehensive, responsive, and cost-flexible database support for MySQL. +Percona XtraBackup is designed to make backups seamless without disrupting the performance of the server in a production environment. Percona XtraBackup (PXB) is a 100% open source backup solution with [commercial support :octicons-link-external-16:](https://www.percona.com/services/expert-support/) available for organizations who want to benefit from comprehensive, responsive, and cost-flexible database support for MySQL. ## Percona XtraBackup features diff --git a/docs/innodb-btree-check.md b/docs/innodb-btree-check.md index 9d33c015..2352570c 100644 --- a/docs/innodb-btree-check.md +++ b/docs/innodb-btree-check.md @@ -2,7 +2,11 @@ ## Overview -Percona XtraBackup 8.4.0-6 introduces the [`--check-tables`](xtrabackup-option-reference.md#check-tables) option that validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. Validation during `--prepare` helps detect corrupted indexes before restore or production deployment. +The [`--check-tables`](xtrabackup-option-reference.md#check-tables) option validates the structural integrity of InnoDB B-tree indexes during the [`--prepare`](xtrabackup-option-reference.md#prepare) phase. Validation during `--prepare` helps detect corrupted indexes before restore or production deployment. + +### Version changes + +Percona XtraBackup 8.4.0-6 introduces the `--check-tables` option. ## Why checksum validation is not enough @@ -10,13 +14,13 @@ Percona XtraBackup verifies InnoDB page checksums during `--backup`. These check Checksum validation detects physical corruption within individual pages, including: -* Torn pages +* Torn-page corruption -* Corrupted writes +* Write corruption * Transfer corruption -* Some storage or filesystem-level corruption +* Storage or filesystem corruption When the server modifies a page while XtraBackup copies it, XtraBackup retries the copy until the checksum becomes consistent. The retry process prevents partially modified pages from entering the backup. @@ -38,19 +42,7 @@ XtraBackup does not validate B-tree structure or relationships between pages dur Structural corruption rarely occurs and usually results from server bugs, backup tool bugs, storage failures, or filesystem-level corruption. -Structural corruption can include: - -* Broken sibling page links - -* Incorrect `PAGE_INDEX_ID` assignments - -* Missing or misplaced minimum-record flags - -* Invalid parent-to-child page references - -* Shared external LOB (large object) pages - -* All-zero pages with valid checksums +Structural corruption can break B-tree page relationships, page metadata consistency, and external LOB references. For a complete list of detected corruption conditions, see [Detected corruption conditions](#detected-corruption-conditions). ## How `--check-tables` works @@ -58,14 +50,6 @@ The `--check-tables` option executes `btr_validate_index()` on every committed i Percona XtraBackup runs validation during the `--prepare` phase after applying the redo log. The validation process operates in read-only mode against backup files and does not modify backup contents. Validation continues after detecting corruption so that Percona XtraBackup can report all problematic tables and indexes in a single run. -The option supports: - -* [Parallel execution](#parallel-execution) through [`--parallel`](xtrabackup-option-reference.md#parallel) - -* Workflows that use [`--apply-log-only`](xtrabackup-option-reference.md#apply-log-only) - -* Transportable tablespace export with [`--export`](xtrabackup-option-reference.md#export) - For each tablespace, Percona XtraBackup: 1. Loads index metadata @@ -78,21 +62,31 @@ For each tablespace, Percona XtraBackup: 5. Reports detected inconsistencies -The validation process verifies: +The option also works with: -* Sibling page relationships +* [Parallel execution](#parallel-execution) through [`--parallel`](xtrabackup-option-reference.md#parallel) -* Parent-to-child page references +* Workflows that use [`--apply-log-only`](xtrabackup-option-reference.md#apply-log-only) -* Page ownership metadata +* Transportable tablespace export with [`--export`](xtrabackup-option-reference.md#export) -* Minimum-record markers +### Detected corruption conditions -* External LOB (large object) page ownership +The validation process performs the following structural checks: + +| Check | Detected condition | +|------|---------------------| +| Broken sibling links | Invalid sibling-page or parent-page navigation pointers | +| `PAGE_INDEX_ID` mismatches | Page index ID does not match index metadata | +| Minimum-record flag validation | Minimum-record flag is missing or invalid | +| Parent-child pointer validation | Child page boundaries do not match parent node structure | +| External LOB validation | Shared, freed, or out-of-bounds LOB page references | +| All-zero page detection | Page contains only zero bytes | +| PRIMARY and secondary index record-count validation | Record count mismatch between the PRIMARY index and secondary indexes | ### Offloading `CHECK TABLE` -The `--check-tables` option provides functionality similar to `CHECK TABLE` for InnoDB tables, but Percona XtraBackup performs validation on backup files during the `--prepare` phase instead of on a running production server. +Similar to the InnoDB `CHECK TABLE` command, the `--check-tables` option validates InnoDB tables. However, Percona XtraBackup performs this validation offline on backup files during the `--prepare` phase, avoiding any performance impact on a live production server. Validation during `--prepare` moves structural integrity verification from restored database instances to the backup preparation workflow. A backup or staging host can run validation without starting MySQL on the restored backup. @@ -106,17 +100,6 @@ Using `--check-tables` during `--prepare` provides the following operational ben * Detects corruption before restore or deployment -### Detected corruption conditions - -| Check | Detected condition | -|------|---------------------| -| Broken sibling links | Invalid sibling-page or parent-page navigation pointers | -| `PAGE_INDEX_ID` mismatches | Page index ID does not match index metadata | -| Minimum-record flag validation | Minimum-record flag is missing or invalid | -| Parent-child pointer validation | Child page boundaries do not match parent node structure | -| External LOB validation | Shared, freed, or out-of-bounds LOB page references | -| All-zero page detection | Page contains only zero bytes | - ### Parallel execution The `--check-tables` option uses the existing `--parallel` infrastructure from Percona XtraBackup. Worker threads process tablespaces independently. @@ -135,19 +118,19 @@ Each worker thread: The `--check-tables` option has the following limitations: +* Validation applies only to InnoDB tables and does not validate MyISAM or RocksDB tables + * Validation runs only during `--prepare` * Validation increases CPU and I/O usage on the backup host * Runtime depends on the number of tablespaces and indexes -* For incremental backup chains, run `--check-tables` only during the final prepare stage because the option verifies all tables and indexes each time it runs - -* Validation does not replace logical consistency checks such as `CHECK TABLE` +* For incremental backup chains, use `--check-tables` only during the final prepare stage because the option verifies all tables and indexes each time it runs ## Usage -The `--check-tables` option uses the thread count specified by `--parallel`. Start with `--parallel=8` and tune the value according to available CPU and disk I/O capacity on the backup host. +The `--check-tables` option uses the thread count specified by `--parallel`. Start with `--parallel=8` and adjust the value according to CPU availability and disk I/O capacity on the backup host. ### Validate a full backup @@ -176,7 +159,7 @@ xtrabackup --prepare --export --check-tables \ ## Output -A successful validation operation ends with: +A successful validation operation typically ends with a message similar to: ```text 2026-05-15T15:41:57.808327+01:00 2 [Note] [MY-011825] [Xtrabackup] Checking: mysql/replication_group_member_actions diff --git a/docs/release-notes/8.4.0-1.md b/docs/release-notes/8.4.0-1.md index b4556890..31f75b38 100644 --- a/docs/release-notes/8.4.0-1.md +++ b/docs/release-notes/8.4.0-1.md @@ -8,7 +8,7 @@ Percona XtraBackup 8.4.0-1 is based on MySQL 8.4 Long Term Supported (LTS) Relea Use the [Percona XtraBackup 8.0 series] to take backups of [Percona Server for MySQL 8.0.x] and MySQL 8.0.x series. -Use the Percona XtraBackup Innovation series, the latest version is [8.3.0-1], to take backups of Percona Server for MySQL Innovation series and MySQL Innovation series. +Use the Percona XtraBackup Innovation series, the latest version is 8.3.0-1, to take backups of Percona Server for MySQL Innovation series and MySQL Innovation series. ## Improvements @@ -38,8 +38,7 @@ Download product binaries, packages, and tarballs at [Percona Product Downloads] [Percona XtraBackup 8.0 series]: https://docs.percona.com/percona-xtrabackup/8.0/ [Percona Server for MySQL 8.0.x]: https://docs.percona.com/percona-server/8.0/ -[8.3.0-1]: https://docs.percona.com/percona-xtrabackup/innovation-release/ [Quickstart Guide for Percona XtraBackup]: ..//quickstart-overview.md -[keyring_vault]: https://docs.percona.com/percona-server/innovation-release/use-keyring-vault-component.html -[Keyring file component]: https://docs.percona.com/percona-server/innovation-release/use-keyring-file.html?h=#use-the-keyring-file-component -[Keyring file plugin]: https://docs.percona.com/percona-server/innovation-release/use-keyring-file.html?h=#use-the-keyring-file-plugin \ No newline at end of file +[keyring_vault]: https://docs.percona.com/percona-server/8.4/use-keyring-vault-component.html +[Keyring file component]: https://docs.percona.com/percona-server/8.4/use-keyring-file.html?h=#use-the-keyring-file-component +[Keyring file plugin]: https://docs.percona.com/percona-server/8.4/use-keyring-file.html?h=#use-the-keyring-file-plugin \ No newline at end of file diff --git a/docs/release-notes/8.4.0-2.md b/docs/release-notes/8.4.0-2.md index f52f1a82..458d3ef5 100644 --- a/docs/release-notes/8.4.0-2.md +++ b/docs/release-notes/8.4.0-2.md @@ -6,7 +6,7 @@ Get started with [Quickstart Guide for Percona XtraBackup]. Percona XtraBackup 8.4.0-2 merges the MySQL 8.4 code base and introduces Percona XtraBackup 8.4.0-2 Pro build, in addition to the regular community builds. -Percona XtraBackup 8.4.0-2 Pro build includes the [capabilities](../pxb-pro.md#capabilities) that are typically requested by large enterprises. These Pro builds are specifically created and tested by Percona, and the corresponding packages are supported only for Percona customers with a valid subscription. +Percona XtraBackup 8.4.0-2 Pro build includes the capabilities that are typically requested by large enterprises. These Pro builds are specifically created and tested by Percona, and the corresponding packages are supported only for Percona customers with a valid subscription. Percona XtraBackup 8.4.0-2 Pro build is available for the following platforms: diff --git a/docs/release-notes/8.4.0-3.md b/docs/release-notes/8.4.0-3.md index 8eaa7047..01273b4b 100644 --- a/docs/release-notes/8.4.0-3.md +++ b/docs/release-notes/8.4.0-3.md @@ -10,7 +10,7 @@ We recommend that you download the Percona XtraBackup for the same platform as t ## Improvements -[PXB-3427](https://perconadev.atlassian.net/browse/PXB-3427): Percona XtraBackup now prepares incremental backups faster. The `--prepare` command directly applies the `.delta` files. To speed up this process, use the [`--parallel=X`](../../xtrabackup-option-reference.md#parallel) option, replacing `X` with the number of threads you want to use simultaneously. This option applies the delta files concurrently. For more information, see [Prepare an incremental backup](../../prepare-incremental-backup.md#faster-prepare-step-with---parallel). +[PXB-3427](https://perconadev.atlassian.net/browse/PXB-3427): Percona XtraBackup now prepares incremental backups faster. The `--prepare` command directly applies the `.delta` files. To speed up this process, use the [`--parallel=X`](../xtrabackup-option-reference.md#parallel) option, replacing `X` with the number of threads you want to use simultaneously. This option applies the delta files concurrently. For more information, see [Prepare an incremental backup](../prepare-incremental-backup.md#faster-prepare-step-with---parallel). [PXB-3199](https://perconadev.atlassian.net/browse/PXB-3199): The `xbcloud put` operations were updated to include support for [ObjectLock-enabled AWS S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) (Thanks to volver for contributing the fix for this issue.) diff --git a/docs/xtrabackup-binary-overview.md b/docs/xtrabackup-binary-overview.md index 23f50f44..0d563ca5 100644 --- a/docs/xtrabackup-binary-overview.md +++ b/docs/xtrabackup-binary-overview.md @@ -74,6 +74,6 @@ Explore the following sections for more guidance: * Configuration options appear on [configure xtrabackup](configure-xtrabackup.md) -* Command-line options: A comprehensive list of command-line options is available on [xtrabackup option reference](xtrabackup-option-reference.html) +* Command-line options: A comprehensive list of command-line options is available on [xtrabackup option reference](xtrabackup-option-reference.md) * Implementation details: Review technical insights and architecture on [xtrabackup implementation details](xtrabackup-implementation-details.md) diff --git a/docs/yum-repo.md b/docs/yum-repo.md index 6f3b8f2b..193ab356 100644 --- a/docs/yum-repo.md +++ b/docs/yum-repo.md @@ -3,9 +3,7 @@ Ready-to-use packages are available from the Percona XtraBackup software repositories and the [Percona Software Downloads :octicons-link-external-16:](https://www.percona.com/downloads). The Percona yum repository supports popular `RPM`-based operating systems, including the `Amazon Linux AMI`. -The easiest way to install the Percona Yum repository is to install an `RPM` that configures yum and installs the [Percona GPG key :octicons-link-external-16:](https://www.percona.com/downloads/RPM-GPG-KEY-percona). - -Specific information on the supported platforms, products, and versions is described in [Percona Software and Platform Lifecycle :octicons-link-external-16:](https://www.percona.com/services/policies/percona-software-platform-lifecycle#mysql). +Specific information on the supported platforms, products, and versions is described in [Percona Software and Platform Lifecycle :octicons-link-external-16:](https://www.percona.com/release-lifecycle-overview/#mysql).