From 8bfac9d20595a35376d0174f431471b9404088cb Mon Sep 17 00:00:00 2001 From: enkilee Date: Tue, 9 Jan 2024 16:04:24 +0800 Subject: [PATCH 1/2] fix 15438 --- br/br-pitr-manual.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 3aa04c5015646..0ff29f2c5da9f 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -368,7 +368,7 @@ Global Flags: The example output only shows the common parameters. These parameters are described as follows: -- `--full-backup-storage`: the storage address for the snapshot (full) backup. To use PITR, specify this parameter and choose the latest snapshot backup before the restore timestamp. To restore only log backup data, you can omit this parameter. Currently, BR supports Amazon S3, GCS, or Azure Blob Storage as the storage for log backup. For details, see [URI Formats of External Storage Services](/external-storage-uri.md). +- `--full-backup-storage`: the storage address for the snapshot (full) backup. To use PITR, specify this parameter and choose the latest snapshot backup before the restore timestamp. To restore only log backup data, you can omit this parameter. Notice that when initializing the recovery cluster for the first time, must specify a backup for snapshot. Currently, BR supports Amazon S3, GCS, or Azure Blob Storage as the storage for log backup. For details, see [URI Formats of External Storage Services](/external-storage-uri.md). - `--restored-ts`: the timestamp that you want to restore data to. If this parameter is not specified, BR restores data to the latest timestamp available in the log backup, that is, the checkpoint of the backup data. - `--start-ts`: the start timestamp that you want to restore log backup data from. If you only need to restore log backup data, you must specify this parameter. - `--pd`: the PD address of the restore cluster. @@ -391,5 +391,6 @@ Restore KV Files <-------------------------------------------------------------- > **Note:** > +> - When you restore the cluster for the first time, it is necessary to specify the full snapshot data, otherwise some data in new created table may be incorrect due to rewriting Table ID rules. > - You cannot restore the log backup data of a certain time period repeatedly. If you restore the log backup data of a range `[t1=10, t2=20)` repeatedly, the restored data might be inconsistent. > - When you restore log data of different time periods in multiple batches, ensure that the log data is restored in consecutive order. If you restore the log backup data of `[t1, t2)`, `[t2, t3)`, and `[t3, t4)` in consecutive order, the restored data is consistent. However, if you restore `[t1, t2)` and then skip `[t2, t3)` to restore `[t3, t4)`, the restored data might be inconsistent. From b41d1fea3f390097db15901f31f4295489cf1a56 Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Mon, 22 Jan 2024 11:10:13 +0800 Subject: [PATCH 2/2] Apply suggestions from code review --- br/br-pitr-manual.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 0ff29f2c5da9f..b63ceeee236b2 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -368,7 +368,7 @@ Global Flags: The example output only shows the common parameters. These parameters are described as follows: -- `--full-backup-storage`: the storage address for the snapshot (full) backup. To use PITR, specify this parameter and choose the latest snapshot backup before the restore timestamp. To restore only log backup data, you can omit this parameter. Notice that when initializing the recovery cluster for the first time, must specify a backup for snapshot. Currently, BR supports Amazon S3, GCS, or Azure Blob Storage as the storage for log backup. For details, see [URI Formats of External Storage Services](/external-storage-uri.md). +- `--full-backup-storage`: the storage address for the snapshot (full) backup. To use PITR, specify this parameter and choose the latest snapshot backup before the restore timestamp. To restore only log backup data, you can omit this parameter. Note that when initializing the recovery cluster for the first time, you must specify a snapshot backup. Currently, BR supports Amazon S3, GCS, and Azure Blob Storage as the storage for log backup. For details, see [URI Formats of External Storage Services](/external-storage-uri.md). - `--restored-ts`: the timestamp that you want to restore data to. If this parameter is not specified, BR restores data to the latest timestamp available in the log backup, that is, the checkpoint of the backup data. - `--start-ts`: the start timestamp that you want to restore log backup data from. If you only need to restore log backup data, you must specify this parameter. - `--pd`: the PD address of the restore cluster. @@ -391,6 +391,6 @@ Restore KV Files <-------------------------------------------------------------- > **Note:** > -> - When you restore the cluster for the first time, it is necessary to specify the full snapshot data, otherwise some data in new created table may be incorrect due to rewriting Table ID rules. +> - When you restore the cluster for the first time, you must specify the full snapshot data. Otherwise, some data in the newly created table might be incorrect due to rewriting Table ID rules. > - You cannot restore the log backup data of a certain time period repeatedly. If you restore the log backup data of a range `[t1=10, t2=20)` repeatedly, the restored data might be inconsistent. > - When you restore log data of different time periods in multiple batches, ensure that the log data is restored in consecutive order. If you restore the log backup data of `[t1, t2)`, `[t2, t3)`, and `[t3, t4)` in consecutive order, the restored data is consistent. However, if you restore `[t1, t2)` and then skip `[t2, t3)` to restore `[t3, t4)`, the restored data might be inconsistent.