From 12939f67cd4c6c9bb775989560f8ec46979df540 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Fri, 25 Oct 2024 11:00:08 +0200 Subject: [PATCH 01/66] subcommands --- en/backup-to-aws-s3-using-br.md | 104 ++++++++++++++++++++++++++++++-- zh/backup-to-aws-s3-using-br.md | 103 ++++++++++++++++++++++++++++++- 2 files changed, 200 insertions(+), 7 deletions(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 24f0f5979..bbd56be37 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -228,6 +228,16 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows log backup operations by taking a `Backup` CR named `demo1-log-backup-s3` as an example. Note that these operations assume that permissions to remote storages are granted using accessKey and secretKey. See the following detailed steps. +#### Log backup subcommands + +The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: + + • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + +These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. + #### Start log backup 1. In the `backup-test` namespace, create a `Backup` CR named `demo1-log-backup-s3`. @@ -247,6 +257,7 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an namespace: backup-test spec: backupMode: log + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 @@ -308,15 +319,101 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. + +```shell +kubectl edit backup demo1-log-backup-s3 -n backup-test +``` + +To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-s3 + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` + +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Running` to `Pause`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-s3 log Pause .... +``` + +#### Resume log backup + +If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. + +```shell +kubectl edit backup demo1-log-backup-s3 -n backup-test +``` + +To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-s3 + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` + +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Running` to `Pause`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-s3 log Running .... +``` + #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. +Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -In the last line of the CR, append `spec.logStop: true`. Then save and quit the editor. The modified content is as follows: +In the last line of the CR, change the change the `logSubcommand` to `log-pause`. Then save and quit the editor. The modified content is as follows: ```yaml --- @@ -337,7 +434,6 @@ spec: region: us-west-1 bucket: my-bucket prefix: my-log-backup-folder - logStop: true ``` You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Running` to `Stopped`: @@ -352,7 +448,7 @@ demo1-log-backup-s3 log Stopped .... ``` -You can also stop log backup by taking the same steps as in [Start log backup](#start-log-backup). The existing `Backup` CR will be updated. +Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. #### Clean log backup data diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index a6f95ea0d..62b7c03ea 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -225,6 +225,16 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。日志备份对远程存储访问授权方式与快照备份一致。本节示例创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，对远程存储访问授权方式仅以通过 accessKey 和 secretKey 的方式为例，具体操作如下所示。 +#### 日志备份的`logSubcommand` + +Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： + + • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + +这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-s3` 的 `Backup` CR。 @@ -305,15 +315,102 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +由于在启动日志备份时已经创建了名为 demo1-log-backup-s3 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 + +```shell +kubectl edit backup demo1-log-backup-s3 -n backup-test +``` + +要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-s3 + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` + + +可以看到名为 `demo1-log-backup-s3` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-s3 log Pause .... +``` + +#### 恢复日志备份 + +如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 + +```shell +kubectl edit backup demo1-log-backup-s3 -n backup-test +``` + +要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-s3 + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 demo1-log-backup-s3 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-s3 log Running .... +``` + #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，停止日志备份。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +在 CR 的最后一行，将 logSubcommand 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -349,7 +446,7 @@ demo1-log-backup-s3 log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 +Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 #### 清理日志备份数据 From 10092d5e062160cfaf1ffb1df1f8b6782db2350d Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Fri, 25 Oct 2024 11:15:24 +0200 Subject: [PATCH 02/66] stop --- en/backup-restore-overview.md | 2 ++ zh/backup-restore-overview.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/en/backup-restore-overview.md b/en/backup-restore-overview.md index 4a68da17b..7c1aae42d 100644 --- a/en/backup-restore-overview.md +++ b/en/backup-restore-overview.md @@ -78,6 +78,8 @@ kubectl delete backupschedule ${name} -n ${namespace} If you use TiDB Operator v1.1.2 or an earlier version, or if you use TiDB Operator v1.1.3 or a later version and set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator cleans the backup data when it deletes the CR. +If you are using version 1.5 or later, when you delete a CR, TiDB Operator will attempt to automatically stop the running log backup task. The auto-stop feature will only stop log backup tasks that are running on track; it does not handle tasks that are in an error or failed state. + If you back up cluster data using AWS EBS volume snapshots and set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator deletes the CR, and cleans up the backup file and the volume snapshots on AWS. In such cases, if you need to delete the namespace, it is recommended that you first delete all the `Backup`/`BackupSchedule` CRs and then delete the namespace. diff --git a/zh/backup-restore-overview.md b/zh/backup-restore-overview.md index d0f763f51..8c59b9c17 100644 --- a/zh/backup-restore-overview.md +++ b/zh/backup-restore-overview.md @@ -78,6 +78,8 @@ kubectl delete backupschedule ${name} -n ${namespace} 如果你使用 v1.1.2 及以前版本，或使用 v1.1.3 及以后版本并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 时会同时清理备份文件。 +如果你使用v1.5及以后的版本，当你删除CR时，TiDB Operator会尝试自动停止正在运行的日志备份任务。自动停止功能只会停止正常运行的日志备份任务，并不处理错误或者失败的任务。 + 如果你使用基于 AWS EBS 卷快照的备份，并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 以及清理备份文件的同时删除 AWS 上相关的所有卷快照。 在满足上述条件时，如果需要删除 namespace，建议首先删除所有的 Backup/BackupSchedule CR，再删除 namespace。 From 1cb9ff683bd58ff8ee75a0568c3b084600f479a7 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Fri, 25 Oct 2024 11:29:20 +0200 Subject: [PATCH 03/66] crd --- en/backup-restore-cr.md | 5 +++++ en/backup-to-aws-s3-using-br.md | 5 +++++ zh/backup-restore-cr.md | 5 +++++ zh/backup-to-aws-s3-using-br.md | 5 +++++ 4 files changed, 20 insertions(+) diff --git a/en/backup-restore-cr.md b/en/backup-restore-cr.md index 2408858fd..d0905cd85 100644 --- a/en/backup-restore-cr.md +++ b/en/backup-restore-cr.md @@ -36,6 +36,11 @@ This section introduces the fields in the `Backup` CR. * `volume-snapshot`: back up data by volume snapshots. * `log`: back up log data in real time in the KV layer. +* `.spec.logSubcommand`: the subcommand for controlling the log backup status in the Backup CR. This field provides three options for managing a log backup task: + * `log-start`: Initiates a new log backup task or resumes an existing task that has been paused. Use this option to start the log backup process or to continue it from a paused state. + * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. + * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + * `.spec.restoreMode`: the restore mode. The default value is `snapshot`, which means restoring data from snapshots in the KV layer. This field is valid only for restore and has three value options currently: * `snapshot`: restore data from snapshots in the KV layer. * `volume-snapshot`: restore data from volume snapshots. diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index bbd56be37..1a685e653 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -238,6 +238,11 @@ The logSubcommand field in the Backup CR allows you to control the status of a l These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. + +In the v1.5 or earily TiDB Operator versions. You could use `logStop: true/false` to stop/start the task. +You are not recommanded to do so in the later versions. + + #### Start log backup 1. In the `backup-test` namespace, create a `Backup` CR named `demo1-log-backup-s3`. diff --git a/zh/backup-restore-cr.md b/zh/backup-restore-cr.md index 6ac9cea4c..50c1decf8 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -34,6 +34,11 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `volume-snapshot`：基于卷快照的备份。 * `log`：从 KV 层备份实时数据变更日志数据。 +* `.spec.logSubcommand`：指定日志备份任务的子命令，用于控制日志备份任务的状态。该字段提供以下三种选项： + * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。可以用于开始日志备份流程或从暂停状态恢复。 + * `log-pause`：暂时暂停正在运行的日志备份任务，可以稍后使用 log-start 命令恢复任务。 + * `log-stop`：永久停止日志备份任务。当此命令发出后，Backup CR 进入停止状态，无法再次启动。 + * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。 * `volume-snapshot`：基于卷快照的 TiDB 集群恢复。 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 62b7c03ea..328bc9ef6 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -235,6 +235,11 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 + +在 TiDB Operator v1.5 或更早的版本中，你可以使用 logStop: true/false 来停止或启动任务。 +然而，不建议在后续版本中继续使用该方式。 + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-s3` 的 `Backup` CR。 From e3d72d70e5439617d829c6231ff1913a4ffd01a9 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Mon, 11 Nov 2024 18:19:37 +0800 Subject: [PATCH 04/66] Update en/backup-to-aws-s3-using-br.md Co-authored-by: Xuecheng Zhang --- en/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 1a685e653..09e4389c6 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -418,7 +418,7 @@ Because you already created a `Backup` CR named `demo1-log-backup-s3` when you s kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -In the last line of the CR, change the change the `logSubcommand` to `log-pause`. Then save and quit the editor. The modified content is as follows: +In the last line of the CR, change the `logSubcommand` to `log-pause`. Then save and quit the editor. The modified content is as follows: ```yaml --- From 52450ede5e1870e293e8560ec659b3a69f1c3275 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Mon, 11 Nov 2024 18:19:49 +0800 Subject: [PATCH 05/66] Update en/backup-to-aws-s3-using-br.md Co-authored-by: Xuecheng Zhang --- en/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 09e4389c6..3adc6a38f 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -326,7 +326,7 @@ Log Checkpoint Ts: 436569119308644661 #### Pause log backup -Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. +Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test From 8674d2c1efb2b35be40e0d7103d8d9f83fdeb30d Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Mon, 11 Nov 2024 12:00:10 +0100 Subject: [PATCH 06/66] fix --- en/backup-restore-overview.md | 2 +- en/backup-to-aws-s3-using-br.md | 4 ++-- zh/backup-to-aws-s3-using-br.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/en/backup-restore-overview.md b/en/backup-restore-overview.md index 7c1aae42d..a94d2a47f 100644 --- a/en/backup-restore-overview.md +++ b/en/backup-restore-overview.md @@ -78,7 +78,7 @@ kubectl delete backupschedule ${name} -n ${namespace} If you use TiDB Operator v1.1.2 or an earlier version, or if you use TiDB Operator v1.1.3 or a later version and set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator cleans the backup data when it deletes the CR. -If you are using version 1.5 or later, when you delete a CR, TiDB Operator will attempt to automatically stop the running log backup task. The auto-stop feature will only stop log backup tasks that are running on track; it does not handle tasks that are in an error or failed state. +If you are using version 1.5.5+ or 1.6.1+, when you delete a CR, TiDB Operator will attempt to automatically stop the running log backup task. The auto-stop feature will only stop log backup tasks that are running on track; it does not handle tasks that are in an error or failed state. If you back up cluster data using AWS EBS volume snapshots and set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator deletes the CR, and cleans up the backup file and the volume snapshots on AWS. diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 3adc6a38f..bb1107685 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -239,8 +239,8 @@ The logSubcommand field in the Backup CR allows you to control the status of a l These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. -In the v1.5 or earily TiDB Operator versions. You could use `logStop: true/false` to stop/start the task. -You are not recommanded to do so in the later versions. +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. #### Start log backup diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 328bc9ef6..710d753ba 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -236,8 +236,8 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 -在 TiDB Operator v1.5 或更早的版本中，你可以使用 logStop: true/false 来停止或启动任务。 -然而，不建议在后续版本中继续使用该方式。 +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 #### 启动日志备份 From 99f9953f75b34a2906b8123630bc142ab14ca34a Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Tue, 12 Nov 2024 08:04:45 +0100 Subject: [PATCH 07/66] lint --- .markdownlint.yaml | 35 ++++++++++++++++++++++++++++++--- en/backup-restore-cr.md | 6 +++--- en/backup-to-aws-s3-using-br.md | 6 +++--- en/renew-tls-certificate.md | 2 +- zh/backup-restore-cr.md | 6 +++--- zh/backup-to-aws-s3-using-br.md | 7 +++---- 6 files changed, 45 insertions(+), 17 deletions(-) diff --git a/.markdownlint.yaml b/.markdownlint.yaml index 33c044282..7ffcdd05d 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -1,97 +1,126 @@ comment: 'Rules for PingCAP docs-tidb-operator' # disable all by default + default: false # MD001 + heading-increment: true # MD003 + heading-style: style: atx # MD009 + # no-trailing-spaces: true # MD010 + no-hard-tabs: true # MD007 + ul-indent: indent: 4 # MD012 + no-multiple-blanks: true # commands-show-output: true # MD018 + no-missing-space-atx: true # MD019 + no-multiple-space-atx: true # MD022 + blanks-around-headings: true # MD023 + heading-start-left: true # MD024 + no-duplicate-heading: siblings_only: true # MD025 + single-title: front_matter_title: '' # MD026 + no-trailing-punctuation: punctuation: '.,;:!。，；：！' # MD027 + no-multiple-space-blockquote: true # MD029 + ol-prefix: style: ordered # MD030 + list-marker-space: true # MD031 + blanks-around-fences: true # MD032 + blanks-around-lists: true # MD034 + no-bare-urls: true # MD037 + no-space-in-emphasis: true # MD038 + no-space-in-code: true # MD039 + no-space-in-links: true # MD042 + no-empty-links: true -# proper-names: -# names: ['TiDB', 'TiKV', 'PingCAP'] -# code_blocks: false +# proper-names + +# names: ['TiDB', 'TiKV', 'PingCAP'] + +# code_blocks: false # MD045 + no-alt-text: true # MD046 + code-block-style: style: fenced # single-trailing-newline: true # MD041 + first-line-heading: true diff --git a/en/backup-restore-cr.md b/en/backup-restore-cr.md index d0905cd85..2f306aa70 100644 --- a/en/backup-restore-cr.md +++ b/en/backup-restore-cr.md @@ -37,9 +37,9 @@ This section introduces the fields in the `Backup` CR. * `log`: back up log data in real time in the KV layer. * `.spec.logSubcommand`: the subcommand for controlling the log backup status in the Backup CR. This field provides three options for managing a log backup task: - * `log-start`: Initiates a new log backup task or resumes an existing task that has been paused. Use this option to start the log backup process or to continue it from a paused state. - * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. - * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + * `log-start`: Initiates a new log backup task or resumes an existing task that has been paused. Use this option to start the log backup process or to continue it from a paused state. + * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. + * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. * `.spec.restoreMode`: the restore mode. The default value is `snapshot`, which means restoring data from snapshots in the KV layer. This field is valid only for restore and has three value options currently: * `snapshot`: restore data from snapshots in the KV layer. diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index bb1107685..8c16c8bac 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -232,9 +232,9 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: - • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. - • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. diff --git a/en/renew-tls-certificate.md b/en/renew-tls-certificate.md index 6fee2cddf..2826837d2 100644 --- a/en/renew-tls-certificate.md +++ b/en/renew-tls-certificate.md @@ -110,7 +110,7 @@ If the original TLS certificates are issued by [the `cfssl` system](enable-tls-b > **Note:** > - > The above command only renews the server-side and the client-side certificate between PD, TiKV, and TiDB components. If you need to renew the server-side certificates for other components, such as TiCDC, TiFlash and TiProxy, you can execute the similar command. + > The above command only renews the server-side and the client-side certificate between PD, TiKV, and TiDB components. If you need to renew the server-side certificates for other components, such as TiCDC, TiFlash and TiProxy, you can execute the similar command. 3. [Perform the rolling restart](restart-a-tidb-cluster.md) to components that need to load the new certificates. diff --git a/zh/backup-restore-cr.md b/zh/backup-restore-cr.md index 50c1decf8..d528cfb13 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -35,9 +35,9 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `log`：从 KV 层备份实时数据变更日志数据。 * `.spec.logSubcommand`：指定日志备份任务的子命令，用于控制日志备份任务的状态。该字段提供以下三种选项： - * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。可以用于开始日志备份流程或从暂停状态恢复。 - * `log-pause`：暂时暂停正在运行的日志备份任务，可以稍后使用 log-start 命令恢复任务。 - * `log-stop`：永久停止日志备份任务。当此命令发出后，Backup CR 进入停止状态，无法再次启动。 + * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。可以用于开始日志备份流程或从暂停状态恢复。 + * `log-pause`：暂时暂停正在运行的日志备份任务，可以稍后使用 log-start 命令恢复任务。 + * `log-stop`：永久停止日志备份任务。当此命令发出后，Backup CR 进入停止状态，无法再次启动。 * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 710d753ba..1e8730192 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -229,9 +229,9 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： - • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 - • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 @@ -352,7 +352,6 @@ spec: prefix: my-log-backup-folder ``` - 可以看到名为 `demo1-log-backup-s3` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： ```shell From 21e686ba4e6d4bc72c8cf1aaa449e05d1a7e0b8d Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Tue, 12 Nov 2024 08:12:05 +0100 Subject: [PATCH 08/66] lint --- en/backup-restore-cr.md | 6 +++--- en/backup-to-aws-s3-using-br.md | 4 +++- zh/backup-restore-cr.md | 6 +++--- zh/backup-to-aws-s3-using-br.md | 4 +++- 4 files changed, 12 insertions(+), 8 deletions(-) diff --git a/en/backup-restore-cr.md b/en/backup-restore-cr.md index 2f306aa70..35c58d46d 100644 --- a/en/backup-restore-cr.md +++ b/en/backup-restore-cr.md @@ -37,9 +37,9 @@ This section introduces the fields in the `Backup` CR. * `log`: back up log data in real time in the KV layer. * `.spec.logSubcommand`: the subcommand for controlling the log backup status in the Backup CR. This field provides three options for managing a log backup task: - * `log-start`: Initiates a new log backup task or resumes an existing task that has been paused. Use this option to start the log backup process or to continue it from a paused state. - * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. - * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + * `log-start`: Initiates a new log backup task or resumes an existing task that has been paused. Use this option to start the log backup process or to continue it from a paused state. + * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. + * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. * `.spec.restoreMode`: the restore mode. The default value is `snapshot`, which means restoring data from snapshots in the KV layer. This field is valid only for restore and has three value options currently: * `snapshot`: restore data from snapshots in the KV layer. diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 8c16c8bac..2f98da0bf 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -233,9 +233,11 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. diff --git a/zh/backup-restore-cr.md b/zh/backup-restore-cr.md index d528cfb13..579f6379e 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -35,9 +35,9 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `log`：从 KV 层备份实时数据变更日志数据。 * `.spec.logSubcommand`：指定日志备份任务的子命令，用于控制日志备份任务的状态。该字段提供以下三种选项： - * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。可以用于开始日志备份流程或从暂停状态恢复。 - * `log-pause`：暂时暂停正在运行的日志备份任务，可以稍后使用 log-start 命令恢复任务。 - * `log-stop`：永久停止日志备份任务。当此命令发出后，Backup CR 进入停止状态，无法再次启动。 + * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。可以用于开始日志备份流程或从暂停状态恢复。 + * `log-pause`：暂时暂停正在运行的日志备份任务，可以稍后使用 log-start 命令恢复任务。 + * `log-stop`：永久停止日志备份任务。当此命令发出后，Backup CR 进入停止状态，无法再次启动。 * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 1e8730192..28074d88a 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -230,9 +230,11 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 From 1c333ce1f2620d533e390940c18470524780d9ab Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Tue, 12 Nov 2024 08:13:44 +0100 Subject: [PATCH 09/66] lint --- en/backup-to-aws-s3-using-br.md | 3 ++- zh/backup-to-aws-s3-using-br.md | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 2f98da0bf..38f8eae0e 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -237,11 +237,12 @@ The logSubcommand field in the Backup CR allows you to control the status of a l • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. - + These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. + However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 28074d88a..5eb380a1a 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -239,6 +239,7 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 + 但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 From 8e6533e99e23638567281273215934de18607e55 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Mon, 25 Nov 2024 11:47:32 +0800 Subject: [PATCH 10/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Xuecheng Zhang --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 5eb380a1a..38446da02 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -385,7 +385,7 @@ metadata: namespace: backup-test spec: backupMode: log - logSubcommand: log-pause + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 From 95d1c683d8a45c07ebeff363b511fcad9f311857 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 02:55:14 +0100 Subject: [PATCH 11/66] fix comment --- en/backup-to-aws-s3-using-br.md | 8 ++++++-- zh/backup-restore-overview.md | 2 +- zh/backup-to-aws-s3-using-br.md | 9 ++++++--- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 38f8eae0e..150c950c1 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -421,7 +421,7 @@ Because you already created a `Backup` CR named `demo1-log-backup-s3` when you s kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -In the last line of the CR, change the `logSubcommand` to `log-pause`. Then save and quit the editor. The modified content is as follows: +Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: ```yaml --- @@ -432,6 +432,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -457,11 +458,13 @@ demo1-log-backup-s3 log Stopped .... Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data -1. Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. +1. Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test @@ -478,6 +481,7 @@ Stopped is the terminated state of a log backup CR, you couldn't change the stat namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/zh/backup-restore-overview.md b/zh/backup-restore-overview.md index 8c59b9c17..251f636dd 100644 --- a/zh/backup-restore-overview.md +++ b/zh/backup-restore-overview.md @@ -78,7 +78,7 @@ kubectl delete backupschedule ${name} -n ${namespace} 如果你使用 v1.1.2 及以前版本，或使用 v1.1.3 及以后版本并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 时会同时清理备份文件。 -如果你使用v1.5及以后的版本，当你删除CR时，TiDB Operator会尝试自动停止正在运行的日志备份任务。自动停止功能只会停止正常运行的日志备份任务，并不处理错误或者失败的任务。 +如果你使用 v1.5.5, v1.6.1 及以后的版本，当你删除CR时，TiDB Operator 会尝试自动停止正在运行的日志备份任务。自动停止功能只会停止正常运行的日志备份任务，并不处理错误或者失败的任务。 如果你使用基于 AWS EBS 卷快照的备份，并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 以及清理备份文件的同时删除 AWS 上相关的所有卷快照。 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 38446da02..153fb7627 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -417,7 +417,7 @@ demo1-log-backup-s3 log Running .... kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -在 CR 的最后一行，将 logSubcommand 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： +将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -428,6 +428,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -438,7 +439,6 @@ spec: region: us-west-1 bucket: my-bucket prefix: my-log-backup-folder - logStop: true ``` 可以看到名为 `demo1-log-backup-s3` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Stopped`： @@ -454,11 +454,13 @@ demo1-log-backup-s3 log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 -1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 +1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test @@ -475,6 +477,7 @@ Stopped 是日志备份的终止状态，此状态下无法再次更改状态， namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 From fd68f5bd3a29c2d29d51786d4fe5b834ae14ec90 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 03:38:30 +0100 Subject: [PATCH 12/66] modify more examples --- en/backup-to-azblob-using-br.md | 104 ++++++++++++++++++++++++++-- en/backup-to-gcs-using-br.md | 117 ++++++++++++++++++++++++++++++-- zh/backup-to-aws-s3-using-br.md | 2 +- zh/backup-to-azblob-using-br.md | 105 ++++++++++++++++++++++++++-- zh/backup-to-gcs-using-br.md | 114 +++++++++++++++++++++++++++++-- 5 files changed, 421 insertions(+), 21 deletions(-) diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 49a7cf8f7..2ce3106bf 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -139,6 +139,24 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-azblob`. See the following detailed steps. +#### Log backup subcommands + +The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: + + • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + +These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. + + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. + +However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. + + #### Start log backup 1. In the `backup-test` namespace, create a `Backup` CR named `demo1-log-backup-azblob`. @@ -158,6 +176,7 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an namespace: backup-test spec: backupMode: log + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 @@ -218,15 +237,87 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. + +```shell +kubectl edit backup log-backup-azblob -n backup-test +``` + +To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot + ``` + +You can view the log backup status by checking the information of the `Backup` CR: + +```shell +kubectl get backup -n backup-test +``` +``` +NAME MODE STATUS .... +log-backup-azblob log Pause .... +``` + +#### Resume log backup + +If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. + +```shell +kubectl edit backup log-backup-azblob.yaml -n backup-test +``` + +To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot + ``` + #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. +Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -In the last line of the CR, append `spec.logStop: true`. Then save and quit the editor. The modified content is as follows: +Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: ```yaml --- @@ -237,6 +328,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -246,7 +338,6 @@ spec: container: my-container prefix: my-log-backup-folder #accessTier: Hot - logStop: true ``` You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-azblob` change from `Running` to `Stopped`: @@ -261,12 +352,14 @@ demo1-log-backup-azblob log Stopped .... ``` -You can stop log backup by taking the same steps as in [Start log backup](#start-log-backup). The existing `Backup` CR will be updated. +Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data -1. Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. +1. Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test @@ -283,6 +376,7 @@ You can stop log backup by taking the same steps as in [Start log backup](#start namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index 1ae57c95d..55955e0b0 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -142,7 +142,25 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac ### Log backup -You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-s3`. See the following detailed steps. +You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-gcs`. See the following detailed steps. + +#### Log backup subcommands + +The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: + + • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + +These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. + + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. + +However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. + #### Start log backup @@ -223,15 +241,99 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Pause`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Pause .... +``` + +#### Resume log backup + +If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Pause`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Running .... +``` + #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. +Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -In the last line of the CR, append `spec.logStop: true`. Then save and quit the editor. The modified content is as follows: +Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: ```yaml --- @@ -242,6 +344,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -251,7 +354,6 @@ spec: secretName: gcs-secret bucket: my-bucket prefix: my-log-backup-folder - logStop: true ``` You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Stopped`: @@ -266,12 +368,14 @@ demo1-log-backup-gcs log Stopped .... ``` -You can also stop log backup by taking the same steps as in [Start log backup](#start-log-backup). The existing `Backup` CR will be updated. +Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data -1. Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. +1. Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test @@ -288,6 +392,7 @@ You can also stop log backup by taking the same steps as in [Start log backup](# namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 153fb7627..007d867f5 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -325,7 +325,7 @@ Log Checkpoint Ts: 436569119308644661 #### 暂停日志备份 -由于在启动日志备份时已经创建了名为 demo1-log-backup-s3 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 +由于在启动日志备份时已经创建了名为 `demo1-log-backup-s3` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 741626ad9..909bb5d07 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -219,15 +219,107 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +由于在启动日志备份时已经创建了名为 `demo1-log-backup-azblob` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 + +```shell +kubectl edit backup demo1-log-backup-azblob -n backup-test +``` + +要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： + + ```shell + kubectl apply -f log-backup-azblob.yaml + ``` + + `log-backup-azblob.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder + ``` + +可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-azblob log Pause .... +``` + +#### 恢复日志备份 + +如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 + +```shell +kubectl edit backup demo1-log-backup-azblob -n backup-test +``` + +要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-azblob + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 demo1-log-backup-azblob 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-azblob log Running .... +``` + #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，停止日志备份。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -238,6 +330,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -247,7 +340,6 @@ spec: container: my-container prefix: my-log-backup-folder #accessTier: Hot - logStop: true ``` 可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Stopped`： @@ -262,12 +354,14 @@ demo1-log-backup-azblob log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 +Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 -1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 +1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test @@ -284,6 +378,7 @@ demo1-log-backup-azblob log Stopped .... namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 112f4fc32..ee8a20628 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -144,6 +144,24 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。日志备份对远程存储访问授权方式与快照备份一致。本节示例创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，具体操作如下所示。 +#### 日志备份的`logSubcommand` + +Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： + + • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + + • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + + • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + +这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 + + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 + +但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-gcs` 的 `Backup` CR。 @@ -223,15 +241,99 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +由于在启动日志备份时已经创建了名为 `demo1-log-backup-gcs` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 `demo1-log-backup-gcs` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Pause .... +``` + +#### 恢复日志备份 + +如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 demo1-log-backup-gcs 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Running .... +``` + #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -242,6 +344,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -266,12 +369,14 @@ demo1-log-backup-gcs log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 +Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 -1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 +1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test @@ -288,6 +393,7 @@ demo1-log-backup-gcs log Stopped .... namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 From a7fc81482969a05ff32756cffc4e8fbc2dd488b3 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 03:45:17 +0100 Subject: [PATCH 13/66] lint --- en/backup-to-azblob-using-br.md | 81 ++++++++++++++------------- en/deploy-tidb-from-kubernetes-gke.md | 4 +- zh/backup-to-azblob-using-br.md | 54 +++++++++--------- zh/deploy-tidb-from-kubernetes-gke.md | 4 +- 4 files changed, 74 insertions(+), 69 deletions(-) diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 2ce3106bf..1fa045684 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -247,32 +247,33 @@ kubectl edit backup log-backup-azblob -n backup-test To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-pause - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - azblob: - secretName: azblob-secret - container: my-container - prefix: my-log-backup-folder - #accessTier: Hot - ``` + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot + ``` You can view the log backup status by checking the information of the `Backup` CR: ```shell kubectl get backup -n backup-test ``` + ``` NAME MODE STATUS .... log-backup-azblob log Pause .... @@ -288,26 +289,26 @@ kubectl edit backup log-backup-azblob.yaml -n backup-test To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-start - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - azblob: - secretName: azblob-secret - container: my-container - prefix: my-log-backup-folder - #accessTier: Hot - ``` + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot + ``` #### Stop log backup diff --git a/en/deploy-tidb-from-kubernetes-gke.md b/en/deploy-tidb-from-kubernetes-gke.md index f4f727352..3974f5c9e 100644 --- a/en/deploy-tidb-from-kubernetes-gke.md +++ b/en/deploy-tidb-from-kubernetes-gke.md @@ -8,7 +8,9 @@ aliases: ['/docs/tidb-in-kubernetes/dev/deploy-tidb-from-kubernetes-gke/'] This document is designed to be directly [run in Google Cloud Shell](https://console.cloud.google.com/cloudshell/open?cloudshell_git_repo=https://github.com/pingcap/docs-tidb-operator&cloudshell_tutorial=en/deploy-tidb-from-kubernetes-gke.md). - + + Google Cloud Shell + It takes you through the following steps: diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 909bb5d07..791242f4f 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -229,33 +229,33 @@ kubectl edit backup demo1-log-backup-azblob -n backup-test 要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： - ```shell - kubectl apply -f log-backup-azblob.yaml - ``` - - `log-backup-azblob.yaml` 文件内容如下： - - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-pause - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - s3: - provider: aws - secretName: s3-secret - region: us-west-1 - bucket: my-bucket - prefix: my-log-backup-folder - ``` + ```shell + kubectl apply -f log-backup-azblob.yaml + ``` + + `log-backup-azblob.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder + ``` 可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： diff --git a/zh/deploy-tidb-from-kubernetes-gke.md b/zh/deploy-tidb-from-kubernetes-gke.md index aea07110c..104509ed1 100644 --- a/zh/deploy-tidb-from-kubernetes-gke.md +++ b/zh/deploy-tidb-from-kubernetes-gke.md @@ -8,7 +8,9 @@ aliases: ['/docs-cn/tidb-in-kubernetes/dev/deploy-tidb-from-kubernetes-gke/'] 本文介绍如何使用 [TiDB Operator](https://github.com/pingcap/tidb-operator) 在 Google Cloud 上部署 TiDB 集群。本教程需要在 [Google Cloud Shell](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/pingcap/docs-tidb-operator&tutorial=zh/deploy-tidb-from-kubernetes-gke.md) 上运行。 - + + Google Cloud Shell + 所包含的步骤如下： From 92522181e982a350349ccc7b0569aca98db34426 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 03:50:55 +0100 Subject: [PATCH 14/66] add version --- en/backup-restore-cr.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/en/backup-restore-cr.md b/en/backup-restore-cr.md index 35c58d46d..e242e4633 100644 --- a/en/backup-restore-cr.md +++ b/en/backup-restore-cr.md @@ -41,6 +41,8 @@ This section introduces the fields in the `Backup` CR. * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + Note that in versions earlier than v1.5.5, this field does not exist. you could use the `logStop`: true/false field to stop or start a task. In the v1.5.5+ and v1.6.1+ verson, the `logStop` is still aviliable but not recommanded. + * `.spec.restoreMode`: the restore mode. The default value is `snapshot`, which means restoring data from snapshots in the KV layer. This field is valid only for restore and has three value options currently: * `snapshot`: restore data from snapshots in the KV layer. * `volume-snapshot`: restore data from volume snapshots. From dc23a0dbaf0ee0c3ce02aae80e3f4b703156dc40 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 11:24:34 +0800 Subject: [PATCH 15/66] Update zh/backup-restore-overview.md Co-authored-by: Cody (Xuecheng) Zhang --- zh/backup-restore-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-restore-overview.md b/zh/backup-restore-overview.md index 251f636dd..f699c0906 100644 --- a/zh/backup-restore-overview.md +++ b/zh/backup-restore-overview.md @@ -78,7 +78,7 @@ kubectl delete backupschedule ${name} -n ${namespace} 如果你使用 v1.1.2 及以前版本，或使用 v1.1.3 及以后版本并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 时会同时清理备份文件。 -如果你使用 v1.5.5, v1.6.1 及以后的版本，当你删除CR时，TiDB Operator 会尝试自动停止正在运行的日志备份任务。自动停止功能只会停止正常运行的日志备份任务，并不处理错误或者失败的任务。 +如果你使用 v1.5.5, v1.6.1 及以后的版本，当你删除 CR 时，TiDB Operator 会尝试自动停止正在运行的日志备份任务。自动停止功能只会停止正常运行的日志备份任务，并不处理错误或者失败的任务。 如果你使用基于 AWS EBS 卷快照的备份，并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 以及清理备份文件的同时删除 AWS 上相关的所有卷快照。 From ef1a001485336d61064d99a2ce76b89f67f1b228 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 11:25:08 +0800 Subject: [PATCH 16/66] Update en/backup-to-aws-s3-using-br.md Co-authored-by: Cody (Xuecheng) Zhang --- en/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 150c950c1..4a40bc9fe 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -243,7 +243,7 @@ These commands allow fine-grained control over the lifecycle of log backup tasks In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +However, you must not mix logStop with logSubcommand in the same CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. #### Start log backup From 33b1b74f38e00f6863692e3c25f632ababc5ea2d Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 11:25:34 +0800 Subject: [PATCH 17/66] Update en/backup-to-aws-s3-using-br.md Co-authored-by: Cody (Xuecheng) Zhang --- en/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 4a40bc9fe..4dc8fc0b8 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -402,7 +402,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Running` to `Pause`: +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Pause` to `Running`: ```shell kubectl get backup -n backup-test From 1bf5060d7eaad8ca83b47f3bd05c550fd5491cba Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 10:26:13 +0100 Subject: [PATCH 18/66] fix comment --- en/backup-to-aws-s3-using-br.md | 10 +++++----- en/backup-to-azblob-using-br.md | 15 +++++++++++++-- en/backup-to-gcs-using-br.md | 6 +++--- zh/backup-to-aws-s3-using-br.md | 4 ++-- zh/backup-to-azblob-using-br.md | 2 +- zh/backup-to-gcs-using-br.md | 4 ++-- 6 files changed, 26 insertions(+), 15 deletions(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 4dc8fc0b8..079a54cbc 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -232,16 +232,16 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: - • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + - log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. - • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + - log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + - log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. -In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. However, you must not mix logStop with logSubcommand in the same CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. @@ -459,7 +459,7 @@ demo1-log-backup-s3 log Stopped .... Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. -In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 1fa045684..5c431bea5 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -152,7 +152,7 @@ The logSubcommand field in the Backup CR allows you to control the status of a l These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. -In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. @@ -310,6 +310,17 @@ To resume the log backup task, you only need to change the `logSubcommand` from #accessTier: Hot ``` +You can see the `STATUS` of the `Backup` CR named `log-backup-azblob` change from `Pause` to `Running`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +log-backup-azblob log Running .... +``` + #### Stop log backup Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. @@ -355,7 +366,7 @@ demo1-log-backup-azblob log Stopped .... Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. -In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index 55955e0b0..084f409db 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -157,7 +157,7 @@ The logSubcommand field in the Backup CR allows you to control the status of a l These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. -In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. @@ -314,7 +314,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Pause`: +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Pause` to `Running`: ```shell kubectl get backup -n backup-test @@ -370,7 +370,7 @@ demo1-log-backup-gcs log Stopped .... Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. -In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 007d867f5..03643996c 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -238,7 +238,7 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 @@ -455,7 +455,7 @@ demo1-log-backup-s3 log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 791242f4f..03fc09d8c 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -356,7 +356,7 @@ demo1-log-backup-azblob log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index ee8a20628..dd11bf8e0 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -157,7 +157,7 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 @@ -371,7 +371,7 @@ demo1-log-backup-gcs log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 From 5132b8b74ac9bd6a013d0f1dc886350af14b920c Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 10:27:11 +0100 Subject: [PATCH 19/66] use - --- en/backup-to-azblob-using-br.md | 6 +++--- en/backup-to-gcs-using-br.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 5c431bea5..8664c4a06 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -143,11 +143,11 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: - • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + - log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. - • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + - log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + - log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index 084f409db..c70d466a2 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -148,11 +148,11 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: - • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + - log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. - • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + - log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + - log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. From 2770c858917b92442b9b394d9b23ec7c8a95785f Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 10:29:02 +0100 Subject: [PATCH 20/66] lint --- en/backup-to-azblob-using-br.md | 6 +++--- en/backup-to-gcs-using-br.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 8664c4a06..2aa082a2d 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -143,11 +143,11 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: - - log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. +- log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. - - log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. +- log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - - log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. +- log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index c70d466a2..cfc946cd2 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -148,11 +148,11 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: - - log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. +- log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. - - log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. +- log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. - - log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. +- log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. From 461ed2a3121b7b2b0c5fce8a49a9050896f651dc Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 10:31:54 +0100 Subject: [PATCH 21/66] fix --- en/backup-to-azblob-using-br.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 2aa082a2d..6894869ef 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -268,7 +268,7 @@ To pause the log backup task, you only need to change the `logSubcommand` from ` #accessTier: Hot ``` -You can view the log backup status by checking the information of the `Backup` CR: +You can see the `STATUS` of the `Backup` CR named `log-backup-azblob` change from `Running` to `Pause`: ```shell kubectl get backup -n backup-test @@ -276,7 +276,7 @@ kubectl get backup -n backup-test ``` NAME MODE STATUS .... -log-backup-azblob log Pause .... +log-backup-azblob log Pause .... ``` #### Resume log backup From be007a3484496b6531077a6daacaa78d04f8c908 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 28 Nov 2024 11:16:26 +0100 Subject: [PATCH 22/66] fix --- en/backup-to-aws-s3-using-br.md | 2 +- en/backup-to-azblob-using-br.md | 2 +- en/backup-to-gcs-using-br.md | 2 +- zh/backup-to-aws-s3-using-br.md | 6 +++--- zh/backup-to-azblob-using-br.md | 20 +++++++++++++++++++- zh/backup-to-gcs-using-br.md | 6 +++--- 6 files changed, 28 insertions(+), 10 deletions(-) diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 079a54cbc..c52d4ed64 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -243,7 +243,7 @@ These commands allow fine-grained control over the lifecycle of log backup tasks In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +However, you must not mix logStop with logSubcommand in the same Backup CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. #### Start log backup diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 6894869ef..c27da0c54 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -154,7 +154,7 @@ These commands allow fine-grained control over the lifecycle of log backup tasks In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +However, you must not mix logStop with logSubcommand in the same Backup CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. #### Start log backup diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index cfc946cd2..9a416bfff 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -159,7 +159,7 @@ These commands allow fine-grained control over the lifecycle of log backup tasks In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +However, you must not mix logStop with logSubcommand in the same Backup CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. #### Start log backup diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 03643996c..5795db6d1 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -238,9 +238,9 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 -但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 +但请勿在同一个 Backup CR 中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 #### 启动日志备份 @@ -455,7 +455,7 @@ demo1-log-backup-s3 log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 03fc09d8c..133003a36 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -140,6 +140,24 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。本节示例创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR。具体操作如下所示。 +#### 日志备份的`logSubcommand` + +Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： + + • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + + • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + + • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + +这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 + + +在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 + +但请勿在同一个 Backup CR 中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-azblob` 的 `Backup` CR。 @@ -356,7 +374,7 @@ demo1-log-backup-azblob log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index dd11bf8e0..fe7460eaa 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -157,9 +157,9 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 -但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 +但请勿在同一个 Backup CR 混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 #### 启动日志备份 @@ -371,7 +371,7 @@ demo1-log-backup-gcs log Stopped .... Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.5/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 From 6882037755f6afb35c37183825ad282a7c389622 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Fri, 29 Nov 2024 07:28:42 +0100 Subject: [PATCH 23/66] =?UTF-8?q?replace=20=E2=80=A2=20with=20-?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- zh/backup-to-aws-s3-using-br.md | 6 +++--- zh/backup-to-azblob-using-br.md | 6 +++--- zh/backup-to-gcs-using-br.md | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 5795db6d1..7174d6ddf 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -229,11 +229,11 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： - • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + - log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 - • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + - log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + - log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 133003a36..8dfbe26fc 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -144,11 +144,11 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： - • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + - log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 - • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + - log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + - log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index fe7460eaa..e07bb55e5 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -148,11 +148,11 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： - • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + - log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 - • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + - log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + - log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 From ce5ac2d94d755fdc6fcf18f18059310161d3b797 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Fri, 29 Nov 2024 07:36:30 +0100 Subject: [PATCH 24/66] lint --- zh/backup-to-azblob-using-br.md | 6 +++--- zh/backup-to-gcs-using-br.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 8dfbe26fc..1938edeea 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -144,11 +144,11 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： - - log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 +- log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 - - log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 +- log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - - log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 +- log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index e07bb55e5..2b07556f1 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -148,11 +148,11 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： - - log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 +- log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 - - log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 +- log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 - - log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 +- log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 From 7dda757dd3f6301c7d7ba80e167df502220c01e9 Mon Sep 17 00:00:00 2001 From: Aolin Date: Wed, 25 Dec 2024 14:07:25 +0800 Subject: [PATCH 25/66] Discard changes to .markdownlint.yaml --- .markdownlint.yaml | 35 +++-------------------------------- 1 file changed, 3 insertions(+), 32 deletions(-) diff --git a/.markdownlint.yaml b/.markdownlint.yaml index 7ffcdd05d..33c044282 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -1,126 +1,97 @@ comment: 'Rules for PingCAP docs-tidb-operator' # disable all by default - default: false # MD001 - heading-increment: true # MD003 - heading-style: style: atx # MD009 - # no-trailing-spaces: true # MD010 - no-hard-tabs: true # MD007 - ul-indent: indent: 4 # MD012 - no-multiple-blanks: true # commands-show-output: true # MD018 - no-missing-space-atx: true # MD019 - no-multiple-space-atx: true # MD022 - blanks-around-headings: true # MD023 - heading-start-left: true # MD024 - no-duplicate-heading: siblings_only: true # MD025 - single-title: front_matter_title: '' # MD026 - no-trailing-punctuation: punctuation: '.,;:!。，；：！' # MD027 - no-multiple-space-blockquote: true # MD029 - ol-prefix: style: ordered # MD030 - list-marker-space: true # MD031 - blanks-around-fences: true # MD032 - blanks-around-lists: true # MD034 - no-bare-urls: true # MD037 - no-space-in-emphasis: true # MD038 - no-space-in-code: true # MD039 - no-space-in-links: true # MD042 - no-empty-links: true -# proper-names - -# names: ['TiDB', 'TiKV', 'PingCAP'] - -# code_blocks: false +# proper-names: +# names: ['TiDB', 'TiKV', 'PingCAP'] +# code_blocks: false # MD045 - no-alt-text: true # MD046 - code-block-style: style: fenced # single-trailing-newline: true # MD041 - first-line-heading: true From f869a8519257cb180cca738aff3439bc39a21c8c Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:28:25 +0800 Subject: [PATCH 26/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 1938edeea..21636e9bf 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -372,9 +372,11 @@ demo1-log-backup-azblob log Stopped .... ``` -Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +`Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + #### 清理日志备份数据 From 1534f5ed42dfbbb195d2a043efc70ea983245a18 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:28:36 +0800 Subject: [PATCH 27/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 21636e9bf..3f1a37b4b 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -337,7 +337,7 @@ demo1-log-backup-azblob log Running .... kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： +将 `logSubcommand` 的值修改为 `log-stop`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From ee452f7de8aa5de9772c5dd64c5f551db6c5c6e5 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:28:54 +0800 Subject: [PATCH 28/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 3f1a37b4b..45f57d662 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -331,7 +331,7 @@ demo1-log-backup-azblob log Running .... #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，停止日志备份。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-stop` 来停止日志备份。下面以停止[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-azblob` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test From 168ed6b0a23cbed716b40d1ae88a5097d78bc2e3 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:29:04 +0800 Subject: [PATCH 29/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 45f57d662..0e7c38694 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -318,7 +318,7 @@ spec: prefix: my-log-backup-folder ``` -可以看到名为 demo1-log-backup-azblob 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： +可以看到名为 `demo1-log-backup-azblob` 的 Backup CR 的 `STATUS` 从 `Paused` 状态变为 `Running`： ```shell kubectl get backup -n backup-test From 015a4d22abb03c3d162e85440860ff2ee57bbeb8 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:29:18 +0800 Subject: [PATCH 30/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 0e7c38694..2e1246630 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -294,7 +294,7 @@ demo1-log-backup-azblob log Pause .... kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： +要恢复日志备份任务，只需将 `logSubcommand` 的值从 `log-pause` 更改为 `log-start`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 1296659d0e762a9570204000acaef3bdb7016909 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:29:34 +0800 Subject: [PATCH 31/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 2e1246630..9b87212a0 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -288,7 +288,11 @@ demo1-log-backup-azblob log Pause .... #### 恢复日志备份 -如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 +如果日志备份任务已暂停，你可以通过将 `logSubcommand` 字段设置为 `log-start` 来恢复该任务。下面以恢复[暂停日志备份](#暂停日志备份)中已暂停的 `demo1-log-backup-azblob` CR 为例。 + +> **Note:** +> +> 此操作仅适用于处于暂停状态 (`Pause`) 的任务，无法恢复状态为 `Fail` 或 `Stopped` 的任务。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test From 760b637c23df4dd2835fd3866f4ba40623f9c630 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:29:59 +0800 Subject: [PATCH 32/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 46 ++++++++++++++++----------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 9b87212a0..0b36983cd 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -251,29 +251,29 @@ kubectl edit backup demo1-log-backup-azblob -n backup-test kubectl apply -f log-backup-azblob.yaml ``` - `log-backup-azblob.yaml` 文件内容如下： - - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-pause - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - s3: - provider: aws - secretName: s3-secret - region: us-west-1 - bucket: my-bucket - prefix: my-log-backup-folder - ``` +修改后 `log-backup-azblob.yaml` 文件内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-azblob + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` 可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： From f13a5cf94312d3aeec093c8c14fc90fcffe7189a Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:30:12 +0800 Subject: [PATCH 33/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 0b36983cd..7fa37e013 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -247,9 +247,9 @@ kubectl edit backup demo1-log-backup-azblob -n backup-test 要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： - ```shell - kubectl apply -f log-backup-azblob.yaml - ``` +```shell +kubectl apply -f log-backup-azblob.yaml +``` 修改后 `log-backup-azblob.yaml` 文件内容如下： From dbb04fd07f66e41a855651c8b00572732671fe28 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:30:29 +0800 Subject: [PATCH 34/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 7fa37e013..2e9951ee1 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -245,7 +245,7 @@ Log Checkpoint Ts: 436569119308644661 kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： +要暂停日志备份任务，只需将 `logSubcommand` 的值从 `log-start` 修改为 `log-pause`，然后保存并退出编辑器。 ```shell kubectl apply -f log-backup-azblob.yaml From 05e8505fb5207343313a29483f853dbf36dbc615 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:30:40 +0800 Subject: [PATCH 35/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 2e9951ee1..9e1be06e0 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -239,7 +239,7 @@ Log Checkpoint Ts: 436569119308644661 #### 暂停日志备份 -由于在启动日志备份时已经创建了名为 `demo1-log-backup-azblob` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-pause` 来暂停日志备份任务。下面以暂停[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-azblob` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test From f29b5fa1ef74c548a0d25f1a4ee2310ce7cc42a4 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:31:03 +0800 Subject: [PATCH 36/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 9e1be06e0..a42aa00ee 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -153,9 +153,11 @@ Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志 这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 -但请勿在同一个 Backup CR 中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + +但是，请勿在同一个 Backup CR 中同时使用 `logStop` 和 `logSubcommand` 字段，这属于不支持的用法。对于 TiDB Operator v1.5.5、v1.6.1 及之后版本，推荐使用 `logSubcommand` 以确保配置清晰且一致。 + #### 启动日志备份 From 734177c5dad69ee5e62bbe5f28473cee3a29ce76 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:31:54 +0800 Subject: [PATCH 37/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index a42aa00ee..f375533a5 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -142,15 +142,15 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- #### 日志备份的`logSubcommand` -Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： +在 Backup 自定义资源 (CR) 中，你可以使用 `logSubcommand` 字段控制日志备份任务的状态。`logSubcommand` 支持以下三个命令： -- log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 +- `log-start`：该命令用于启动新的日志备份任务，或恢复已暂停的任务。使用此命令可以开始日志备份流程，或从暂停状态恢复任务。 -- log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 +- `log-pause`：该命令用于暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 -- log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 - -这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 +- `log-stop`：该命令用于永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 + +这些命令提供了对日志备份任务生命周期的精细控制，支持启动、暂停、恢复和停止操作，帮助有效管理 Kubernetes 环境中的日志数据保留。 From 55b2671b869548576576be15b8243e110914e556 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:32:07 +0800 Subject: [PATCH 38/66] Update zh/backup-to-azblob-using-br.md Co-authored-by: Aolin --- zh/backup-to-azblob-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index f375533a5..2bd212f49 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -140,7 +140,7 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。本节示例创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR。具体操作如下所示。 -#### 日志备份的`logSubcommand` +#### `logSubcommand` 字段说明 在 Backup 自定义资源 (CR) 中，你可以使用 `logSubcommand` 字段控制日志备份任务的状态。`logSubcommand` 支持以下三个命令： From 041af464582603638cc9881ef0baafa9a8cf56ab Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:32:27 +0800 Subject: [PATCH 39/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 2b07556f1..8f29fc69b 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -369,9 +369,9 @@ demo1-log-backup-gcs log Stopped .... ``` -Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 +`Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 -在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 #### 清理日志备份数据 From f80c664c1b03d73ffccc9b5812926f40201c8ada Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:32:36 +0800 Subject: [PATCH 40/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 8f29fc69b..1e5790866 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -333,7 +333,7 @@ demo1-log-backup-gcs log Running .... kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： +将 `logSubcommand` 的值修改为 `log-stop`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 8f56e79631f5f304d7321a1514b4faa4097dd4ed Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:33:21 +0800 Subject: [PATCH 41/66] Update zh/backup-restore-cr.md Co-authored-by: Aolin --- zh/backup-restore-cr.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zh/backup-restore-cr.md b/zh/backup-restore-cr.md index 579f6379e..5571bdca0 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -34,10 +34,10 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `volume-snapshot`：基于卷快照的备份。 * `log`：从 KV 层备份实时数据变更日志数据。 -* `.spec.logSubcommand`：指定日志备份任务的子命令，用于控制日志备份任务的状态。该字段提供以下三种选项： - * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。可以用于开始日志备份流程或从暂停状态恢复。 - * `log-pause`：暂时暂停正在运行的日志备份任务，可以稍后使用 log-start 命令恢复任务。 - * `log-stop`：永久停止日志备份任务。当此命令发出后，Backup CR 进入停止状态，无法再次启动。 +* `.spec.logSubcommand`：指定日志备份任务的子命令，用于控制日志备份任务的状态。该字段支持以下三个选项： + * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。使用此命令可以开始日志备份流程，或从暂停状态恢复任务。 + * `log-pause`：暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 + * `log-stop`：永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。 From 0268bf1d1181b08fc9ed490d3b43a337fa236897 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:34:00 +0800 Subject: [PATCH 42/66] Update zh/backup-restore-overview.md Co-authored-by: Aolin --- zh/backup-restore-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-restore-overview.md b/zh/backup-restore-overview.md index f699c0906..d59337547 100644 --- a/zh/backup-restore-overview.md +++ b/zh/backup-restore-overview.md @@ -78,7 +78,7 @@ kubectl delete backupschedule ${name} -n ${namespace} 如果你使用 v1.1.2 及以前版本，或使用 v1.1.3 及以后版本并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 时会同时清理备份文件。 -如果你使用 v1.5.5, v1.6.1 及以后的版本，当你删除 CR 时，TiDB Operator 会尝试自动停止正在运行的日志备份任务。自动停止功能只会停止正常运行的日志备份任务，并不处理错误或者失败的任务。 +如果你使用 v1.5.5、v1.6.1 及之后的版本，当你删除 CR 时，TiDB Operator 会尝试自动停止正在运行的日志备份任务。此自动停止功能仅适用于正常运行的日志备份任务，不会处理出现错误或失败状态的任务。 如果你使用基于 AWS EBS 卷快照的备份，并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 以及清理备份文件的同时删除 AWS 上相关的所有卷快照。 From ec8d4f0741156d5df4d10f1ae2eaa787c251212e Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Thu, 26 Dec 2024 16:34:37 +0800 Subject: [PATCH 43/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 7174d6ddf..eff8d7d23 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -225,7 +225,7 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。日志备份对远程存储访问授权方式与快照备份一致。本节示例创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，对远程存储访问授权方式仅以通过 accessKey 和 secretKey 的方式为例，具体操作如下所示。 -#### 日志备份的`logSubcommand` +#### `logSubcommand` 字段说明 Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： From 445bb38484fa4035d04c867aad58786fc49f9501 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:34:35 +0800 Subject: [PATCH 44/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 1e5790866..e0f11f79a 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -327,7 +327,7 @@ demo1-log-backup-gcs log Running .... #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-stop` 来停止日志备份。下面以停止[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-gcs` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test From 672f64088771b6e9636a2e2b215dbd9041c7ae59 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:35:07 +0800 Subject: [PATCH 45/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index eff8d7d23..9bb9f0f63 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -227,15 +227,15 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu #### `logSubcommand` 字段说明 -Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： +在 Backup 自定义资源 (CR) 中，你可以使用 `logSubcommand` 字段控制日志备份任务的状态。`logSubcommand` 支持以下三个命令： - - log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 +- `log-start`：该命令用于启动新的日志备份任务，或恢复已暂停的任务。使用此命令可以开始日志备份流程，或从暂停状态恢复任务。 - - log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 +- `log-pause`：该命令用于暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 - - log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 - -这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 +- `log-stop`：该命令用于永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 + +这些命令提供了对日志备份任务生命周期的精细控制，支持启动、暂停、恢复和停止操作，帮助有效管理 Kubernetes 环境中的日志数据保留。 在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 From a9284cc8bd73642926d68d6e77efd5cb57a680c2 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:35:38 +0800 Subject: [PATCH 46/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 9bb9f0f63..51173df56 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -238,9 +238,11 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu 这些命令提供了对日志备份任务生命周期的精细控制，支持启动、暂停、恢复和停止操作，帮助有效管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 -但请勿在同一个 Backup CR 中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + +但是，请勿在同一个 Backup CR 中同时使用 `logStop` 和 `logSubcommand` 字段，这属于不支持的用法。对于 TiDB Operator v1.5.5、v1.6.1 及之后版本，推荐使用 `logSubcommand` 以确保配置清晰且一致。 + #### 启动日志备份 From eddbf6c2e995a47f54e7f45869378d730eb61476 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:35:59 +0800 Subject: [PATCH 47/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 51173df56..daf809e00 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -333,7 +333,7 @@ Log Checkpoint Ts: 436569119308644661 kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： +要暂停日志备份任务，只需将 `logSubcommand` 的值从 `log-start` 修改为 `log-pause`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 836edde94674a12d8bf42e20f97f7470898f3d5f Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:36:26 +0800 Subject: [PATCH 48/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index daf809e00..0c4b3eb12 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -327,7 +327,7 @@ Log Checkpoint Ts: 436569119308644661 #### 暂停日志备份 -由于在启动日志备份时已经创建了名为 `demo1-log-backup-s3` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-pause` 来暂停日志备份任务。下面以暂停[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-s3` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test From 1d62216bada86655cfe8094c76e79c39a37899dd Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:37:20 +0800 Subject: [PATCH 49/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 0c4b3eb12..9b1853775 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -370,7 +370,11 @@ demo1-log-backup-s3 log Pause .... #### 恢复日志备份 -如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 +如果日志备份任务已暂停，你可以通过将 `logSubcommand` 字段设置为 `log-start` 来恢复该任务。下面以恢复[暂停日志备份](#暂停日志备份)中已暂停的 `demo1-log-backup-s3` CR 为例。 + +> **Note:** +> +> 此操作仅适用于处于暂停状态 (`Pause`) 的任务，无法恢复状态为 `Fail` 或 `Stopped` 的任务。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test From 77497fdf93b05368c4ccb58e0ae47a698e269968 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:37:37 +0800 Subject: [PATCH 50/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 9b1853775..d8826b1e6 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -380,7 +380,7 @@ demo1-log-backup-s3 log Pause .... kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： +要恢复日志备份任务，只需将 `logSubcommand` 的值从 `log-pause` 更改为 `log-start`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 279a215ab19a1e529140ef2936c1a0bbbf9a1722 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:37:51 +0800 Subject: [PATCH 51/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index d8826b1e6..87cb906d0 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -404,7 +404,7 @@ spec: prefix: my-log-backup-folder ``` -可以看到名为 demo1-log-backup-s3 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： +可以看到名为 `demo1-log-backup-s3` 的 Backup CR 的 `STATUS` 从 `Paused` 状态变为 `Running`： ```shell kubectl get backup -n backup-test From 08d675a302b028dd498db917c20e9c57ff79b8d9 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:38:09 +0800 Subject: [PATCH 52/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 87cb906d0..3dde0baa6 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -417,7 +417,7 @@ demo1-log-backup-s3 log Running .... #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-s3` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，停止日志备份。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-stop` 来停止日志备份。下面以停止[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-s3` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test From ab19385f5737392549bff009f9c4226bf887f0c9 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:38:22 +0800 Subject: [PATCH 53/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 3dde0baa6..05893bbcc 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -423,7 +423,7 @@ demo1-log-backup-s3 log Running .... kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： +将 `logSubcommand` 的值修改为 `log-stop`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 41807a2ca0a0b451074b12e42931ceeb13c9af98 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:38:40 +0800 Subject: [PATCH 54/66] Update zh/backup-to-aws-s3-using-br.md Co-authored-by: Aolin --- zh/backup-to-aws-s3-using-br.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 05893bbcc..a9c33aeca 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -459,9 +459,11 @@ demo1-log-backup-s3 log Stopped .... ``` -Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 -在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 +`Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + #### 清理日志备份数据 From d676ce8bd67ae40b480f342b10e93148ec4a3969 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:38:59 +0800 Subject: [PATCH 55/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index e0f11f79a..d093b8d08 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -144,7 +144,7 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。日志备份对远程存储访问授权方式与快照备份一致。本节示例创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，具体操作如下所示。 -#### 日志备份的`logSubcommand` +#### `logSubcommand` 字段说明 Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： From a512ca0b7d23db8291b7f479e88fe2327cbbe26b Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:39:59 +0800 Subject: [PATCH 56/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index d093b8d08..59517fd35 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -146,15 +146,15 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac #### `logSubcommand` 字段说明 -Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： +在 Backup 自定义资源 (CR) 中，你可以使用 `logSubcommand` 字段控制日志备份任务的状态。`logSubcommand` 支持以下三个命令： -- log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 +- `log-start`：该命令用于启动新的日志备份任务，或恢复已暂停的任务。使用此命令可以开始日志备份流程，或从暂停状态恢复任务。 -- log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 +- `log-pause`：该命令用于暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 -- log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 - -这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 +- `log-stop`：该命令用于永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 + +这些命令提供了对日志备份任务生命周期的精细控制，支持启动、暂停、恢复和停止操作，帮助有效管理 Kubernetes 环境中的日志数据保留。 在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 From b7c88bcb953981803de9a43488ba6d2a8f3b8ff6 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 16:40:42 +0800 Subject: [PATCH 57/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 59517fd35..e6640441f 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -157,9 +157,11 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac 这些命令提供了对日志备份任务生命周期的精细控制，支持启动、暂停、恢复和停止操作，帮助有效管理 Kubernetes 环境中的日志数据保留。 -在 v1.5.4/v1.6.0 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 -但请勿在同一个 Backup CR 混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + +但是，请勿在同一个 Backup CR 中同时使用 `logStop` 和 `logSubcommand` 字段，这属于不支持的用法。对于 TiDB Operator v1.5.5、v1.6.1 及之后版本，推荐使用 `logSubcommand` 以确保配置清晰且一致。 + #### 启动日志备份 From c0f963e5daf2f18c062e35c16aff2fccdc494d57 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 17:08:56 +0800 Subject: [PATCH 58/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index e6640441f..851332ce5 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -316,7 +316,7 @@ spec: prefix: my-log-backup-folder ``` -可以看到名为 demo1-log-backup-gcs 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： +可以看到名为 `demo1-log-backup-gcs` 的 Backup CR 的 `STATUS` 从 `Paused` 状态变为 `Running`： ```shell kubectl get backup -n backup-test From 4e47ffb977c0a42c7f2c2ef34dcb6ebb3e4ddd54 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 17:09:09 +0800 Subject: [PATCH 59/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 851332ce5..9f08b7a06 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -293,7 +293,7 @@ demo1-log-backup-gcs log Pause .... kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： +要恢复日志备份任务，只需将 `logSubcommand` 的值从 `log-pause` 更改为 `log-start`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 95c2695a7b7d440c82bc6b25c461817788ef0732 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 17:15:14 +0800 Subject: [PATCH 60/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 9f08b7a06..880288f35 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -251,7 +251,7 @@ Log Checkpoint Ts: 436569119308644661 kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： +要暂停日志备份任务，只需将 `logSubcommand` 的值从 `log-start` 修改为 `log-pause`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- From 6df8bb8a30ae6ea975e0ae9337189b9df24b9128 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 17:15:32 +0800 Subject: [PATCH 61/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 880288f35..c8d8fc831 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -287,7 +287,11 @@ demo1-log-backup-gcs log Pause .... #### 恢复日志备份 -如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 +如果日志备份任务已暂停，你可以通过将 `logSubcommand` 字段设置为 `log-start` 来恢复该任务。下面以恢复[暂停日志备份](#暂停日志备份)中已暂停的 `demo1-log-backup-gcs` CR 为例。 + +> **Note:** +> +> 此操作仅适用于处于暂停状态 (`Pause`) 的任务，无法恢复状态为 `Fail` 或 `Stopped` 的任务。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test From 9d70fc0f24b1970f4440830bd1b34fd8e0b93d95 Mon Sep 17 00:00:00 2001 From: ris <79858083+RidRisR@users.noreply.github.com> Date: Fri, 27 Dec 2024 17:15:50 +0800 Subject: [PATCH 62/66] Update zh/backup-to-gcs-using-br.md Co-authored-by: Aolin --- zh/backup-to-gcs-using-br.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index c8d8fc831..5343249a5 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -245,7 +245,7 @@ Log Checkpoint Ts: 436569119308644661 #### 暂停日志备份 -由于在启动日志备份时已经创建了名为 `demo1-log-backup-gcs` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-pause` 来暂停日志备份任务。下面以暂停[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-gcs` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test From c201b83cf5d7852af159fe4edbb4cf058e162b80 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Thu, 16 Jan 2025 09:13:36 +0100 Subject: [PATCH 63/66] fix wrong storage type --- zh/backup-to-azblob-using-br.md | 48 +++++++++++++++------------------ 1 file changed, 22 insertions(+), 26 deletions(-) diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 2bd212f49..9f0e77a0d 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -255,27 +255,25 @@ kubectl apply -f log-backup-azblob.yaml 修改后 `log-backup-azblob.yaml` 文件内容如下： -```yaml ---- -apiVersion: pingcap.com/v1alpha1 -kind: Backup -metadata: - name: demo1-log-backup-azblob - namespace: backup-test -spec: - backupMode: log - logSubcommand: log-pause - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - s3: - provider: aws - secretName: s3-secret - region: us-west-1 - bucket: my-bucket - prefix: my-log-backup-folder -``` + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + ``` 可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： @@ -316,11 +314,9 @@ spec: cluster: demo1 clusterNamespace: test1 sendCredToTikv: true - s3: - provider: aws - secretName: s3-secret - region: us-west-1 - bucket: my-bucket + azblob: + secretName: azblob-secret + container: my-container prefix: my-log-backup-folder ``` From 04dcaac2b12a651a42e20f197335ce57ceec550c Mon Sep 17 00:00:00 2001 From: Aolin Date: Fri, 17 Jan 2025 18:29:27 +0800 Subject: [PATCH 64/66] align with Chinese and revise wording --- en/backup-restore-cr.md | 8 +- en/backup-restore-overview.md | 2 +- en/backup-to-aws-s3-using-br.md | 46 +++++----- en/backup-to-azblob-using-br.md | 147 +++++++++++++++++--------------- en/backup-to-gcs-using-br.md | 47 +++++----- zh/backup-to-azblob-using-br.md | 41 ++++----- zh/backup-to-gcs-using-br.md | 4 +- 7 files changed, 164 insertions(+), 131 deletions(-) diff --git a/en/backup-restore-cr.md b/en/backup-restore-cr.md index e242e4633..640a9e17e 100644 --- a/en/backup-restore-cr.md +++ b/en/backup-restore-cr.md @@ -37,11 +37,11 @@ This section introduces the fields in the `Backup` CR. * `log`: back up log data in real time in the KV layer. * `.spec.logSubcommand`: the subcommand for controlling the log backup status in the Backup CR. This field provides three options for managing a log backup task: - * `log-start`: Initiates a new log backup task or resumes an existing task that has been paused. Use this option to start the log backup process or to continue it from a paused state. - * `log-pause`: Temporarily pauses an active log backup task, allowing it to be resumed later using the log-start command. - * `log-stop`: Permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + * `log-start`: initiates a new log backup task or resumes a paused task. Use this command to start the log backup process or resume a task from a paused state. + * `log-pause`: temporarily pauses the currently running log backup task. After pausing, you can use the `log-start` command to resume the task. + * `log-stop`: permanently stops the log backup task. After executing this command, the Backup CR enters a stopped state and cannot be restarted. - Note that in versions earlier than v1.5.5, this field does not exist. you could use the `logStop`: true/false field to stop or start a task. In the v1.5.5+ and v1.6.1+ verson, the `logStop` is still aviliable but not recommanded. + For versions before v1.5.5, use the `logStop` field with boolean values (`true`/`false`) to control log backup operations. While `logStop` is still supported in v1.5.5 and v1.6.1, it is recommended to use `logSubcommand` instead. * `.spec.restoreMode`: the restore mode. The default value is `snapshot`, which means restoring data from snapshots in the KV layer. This field is valid only for restore and has three value options currently: * `snapshot`: restore data from snapshots in the KV layer. diff --git a/en/backup-restore-overview.md b/en/backup-restore-overview.md index a94d2a47f..5923fd439 100644 --- a/en/backup-restore-overview.md +++ b/en/backup-restore-overview.md @@ -78,7 +78,7 @@ kubectl delete backupschedule ${name} -n ${namespace} If you use TiDB Operator v1.1.2 or an earlier version, or if you use TiDB Operator v1.1.3 or a later version and set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator cleans the backup data when it deletes the CR. -If you are using version 1.5.5+ or 1.6.1+, when you delete a CR, TiDB Operator will attempt to automatically stop the running log backup task. The auto-stop feature will only stop log backup tasks that are running on track; it does not handle tasks that are in an error or failed state. +If you use v1.5.5, v1.6.1, or a later version, TiDB Operator automatically attempts to stop running log backup tasks when you delete the Custom Resource (CR). This automatic stop feature only applies to log backup tasks that are running normally and does not handle tasks in an error or failed state. If you back up cluster data using AWS EBS volume snapshots and set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator deletes the CR, and cleans up the backup file and the volume snapshots on AWS. diff --git a/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index c52d4ed64..b2c3b9eec 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -228,22 +228,24 @@ demo1-full-backup-s3 full snapshot Complete s3://my-bucket/my-full-backu You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows log backup operations by taking a `Backup` CR named `demo1-log-backup-s3` as an example. Note that these operations assume that permissions to remote storages are granted using accessKey and secretKey. See the following detailed steps. -#### Log backup subcommands +#### Description of the `logSubcommand` field -The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: +In the Backup Custom Resource (CR), you can use the `logSubcommand` field to control the state of a log backup task. The `logSubcommand` field supports the following commands: - - log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. +- `log-start`: initiates a new log backup task or resumes a paused task. Use this command to start the log backup process or resume a task from a paused state. - - log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. +- `log-pause`: temporarily pauses the currently running log backup task. After pausing, you can use the `log-start` command to resume the task. - - log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. +- `log-stop`: permanently stops the log backup task. After executing this command, the Backup CR enters a stopped state and cannot be restarted. -These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. +These commands provide fine-grained control over the lifecycle of log backup tasks, enabling you to start, pause, resume, and stop tasks effectively to manage log data retention in Kubernetes environments. -In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same Backup CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +In TiDB Operator v1.5.4, v1.6.0, and earlier versions, you can use the `logStop: true/false` field to stop or start log backup tasks. This field is retained for backward compatibility. + +However, do not use `logStop` and `logSubcommand` fields in the same Backup CR, as this is not supported. For TiDB Operator v1.5.5, v1.6.1, and later versions, it is recommended to use the `logSubcommand` field to ensure clear and consistent configuration. + #### Start log backup @@ -329,13 +331,13 @@ Log Checkpoint Ts: 436569119308644661 #### Pause log backup -Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. +You can pause a log backup task by setting the `logSubcommand` field of the Backup Custom Resource (CR) to `log-pause`. The following example shows how to pause the `demo1-log-backup-s3` CR created in [Start log backup](#start-log-backup). ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: +To pause the log backup task, change the value of `logSubcommand` from `log-start` to `log-pause`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -359,7 +361,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Running` to `Pause`: +You can verify that the `STATUS` of the `demo1-log-backup-s3` Backup CR changes from `Running` to `Pause`: ```shell kubectl get backup -n backup-test @@ -372,13 +374,17 @@ demo1-log-backup-s3 log Pause .... #### Resume log backup -If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. +If a log backup task is paused, you can resume it by setting the `logSubcommand` field to `log-start`. The following example shows how to resume the `demo1-log-backup-s3` CR that was paused in [Pause Log Backup](#pause-log-backup). + +> **Note:** +> +> This operation applies only to tasks in the `Pause` state. You cannot resume tasks in the `Fail` or `Stopped` state. ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: +To resume the log backup task, change the value of `logSubcommand` from `log-pause` to `log-start`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -402,7 +408,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Pause` to `Running`: +You can verify that the `STATUS` of the `demo1-log-backup-s3` Backup CR changes from `Pause` to `Running`: ```shell kubectl get backup -n backup-test @@ -415,13 +421,13 @@ demo1-log-backup-s3 log Running .... #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-s3` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. +You can stop a log backup task by setting the `logSubcommand` field of the Backup Custom Resource (CR) to `log-stop`. The following example shows how to stop the `demo1-log-backup-s3` CR created in [Start log backup](#start-log-backup). ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: +Change the value of `logSubcommand` to `log-stop`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -445,7 +451,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` change from `Running` to `Stopped`: +You can verify that the `STATUS` of the `Backup` CR named `demo1-log-backup-s3` changes from `Running` to `Stopped`: ```shell kubectl get backup -n backup-test @@ -457,9 +463,11 @@ demo1-log-backup-s3 log Stopped .... ``` -Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. -In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +`Stopped` is the terminal state for log backup. In this state, you cannot change the backup state again, but you can still clean up the log backup data. + +In TiDB Operator v1.5.4, v1.6.0, and earlier versions, you can use the `logStop: true/false` field to stop or start log backup tasks. This field is retained for backward compatibility. + #### Clean log backup data diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index c27da0c54..08d9fb5b4 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -139,22 +139,24 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-azblob`. See the following detailed steps. -#### Log backup subcommands +#### Description of the `logSubcommand` field -The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: +In the Backup Custom Resource (CR), you can use the `logSubcommand` field to control the state of a log backup task. The `logSubcommand` field supports the following commands: -- log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. +- `log-start`: initiates a new log backup task or resumes a paused task. Use this command to start the log backup process or resume a task from a paused state. -- log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. +- `log-pause`: temporarily pauses the currently running log backup task. After pausing, you can use the `log-start` command to resume the task. -- log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. +- `log-stop`: permanently stops the log backup task. After executing this command, the Backup CR enters a stopped state and cannot be restarted. -These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. +These commands provide fine-grained control over the lifecycle of log backup tasks, enabling you to start, pause, resume, and stop tasks effectively to manage log data retention in Kubernetes environments. -In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same Backup CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +In TiDB Operator v1.5.4, v1.6.0, and earlier versions, you can use the `logStop: true/false` field to stop or start log backup tasks. This field is retained for backward compatibility. + +However, do not use `logStop` and `logSubcommand` fields in the same Backup CR, as this is not supported. For TiDB Operator v1.5.5, v1.6.1, and later versions, it is recommended to use the `logSubcommand` field to ensure clear and consistent configuration. + #### Start log backup @@ -239,36 +241,41 @@ Log Checkpoint Ts: 436569119308644661 #### Pause log backup -Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. +You can pause a log backup task by setting the `logSubcommand` field of the Backup Custom Resource (CR) to `log-pause`. The following example shows how to pause the `demo1-log-backup-azblob` CR created in [Start log backup](#start-log-backup). + +```shell +kubectl edit backup demo1-log-backup-azblob -n backup-test +``` + +To pause the log backup task, change the value of `logSubcommand` from `log-start` to `log-pause`, then save and exit the editor. ```shell -kubectl edit backup log-backup-azblob -n backup-test +kubectl apply -f log-backup-azblob.yaml +``` + +The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-azblob + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder ``` -To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: - - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-pause - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - azblob: - secretName: azblob-secret - container: my-container - prefix: my-log-backup-folder - #accessTier: Hot - ``` - -You can see the `STATUS` of the `Backup` CR named `log-backup-azblob` change from `Running` to `Pause`: +You can verify that the `STATUS` of the `demo1-log-backup-azblob` Backup CR changes from `Running` to `Pause`: ```shell kubectl get backup -n backup-test @@ -276,41 +283,45 @@ kubectl get backup -n backup-test ``` NAME MODE STATUS .... -log-backup-azblob log Pause .... +demo1-log-backup-azblob log Pause .... ``` #### Resume log backup -If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. +If a log backup task is paused, you can resume it by setting the `logSubcommand` field to `log-start`. The following example shows how to resume the `demo1-log-backup-azblob` CR that was paused in [Pause Log Backup](#pause-log-backup). + +> **Note:** +> +> This operation applies only to tasks in the `Pause` state. You cannot resume tasks in the `Fail` or `Stopped` state. ```shell -kubectl edit backup log-backup-azblob.yaml -n backup-test +kubectl edit backup demo1-log-backup-azblob -n backup-test +``` + +To resume the log backup task, change the value of `logSubcommand` from `log-pause` to `log-start`, then save and exit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-azblob + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot ``` -To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: - - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-start - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - azblob: - secretName: azblob-secret - container: my-container - prefix: my-log-backup-folder - #accessTier: Hot - ``` - -You can see the `STATUS` of the `Backup` CR named `log-backup-azblob` change from `Pause` to `Running`: +You can verify that the `STATUS` of the `demo1-log-backup-azblob` Backup CR changes from `Pause` to `Running`: ```shell kubectl get backup -n backup-test @@ -318,18 +329,18 @@ kubectl get backup -n backup-test ``` NAME MODE STATUS .... -log-backup-azblob log Running .... +demo1-log-backup-azblob log Running .... ``` #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. +You can stop a log backup task by setting the `logSubcommand` field of the Backup Custom Resource (CR) to `log-stop`. The following example shows how to stop the `demo1-log-backup-azblob` CR created in [Start log backup](#start-log-backup). ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: +Change the value of `logSubcommand` to `log-stop`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -352,7 +363,7 @@ spec: #accessTier: Hot ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-azblob` change from `Running` to `Stopped`: +You can verify that the `STATUS` of the `Backup` CR named `demo1-log-backup-azblob` changes from `Running` to `Stopped`: ```shell kubectl get backup -n backup-test @@ -364,9 +375,11 @@ demo1-log-backup-azblob log Stopped .... ``` -Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. -In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +`Stopped` is the terminal state for log backup. In this state, you cannot change the backup state again, but you can still clean up the log backup data. + +In TiDB Operator v1.5.4, v1.6.0, and earlier versions, you can use the `logStop: true/false` field to stop or start log backup tasks. This field is retained for backward compatibility. + #### Clean log backup data diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index 9a416bfff..6c9e8e648 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -144,22 +144,24 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-gcs`. See the following detailed steps. -#### Log backup subcommands +#### Description of the `logSubcommand` field -The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: +In the Backup Custom Resource (CR), you can use the `logSubcommand` field to control the state of a log backup task. The `logSubcommand` field supports the following commands: -- log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. +- `log-start`: initiates a new log backup task or resumes a paused task. Use this command to start the log backup process or resume a task from a paused state. -- log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. +- `log-pause`: temporarily pauses the currently running log backup task. After pausing, you can use the `log-start` command to resume the task. -- log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. +- `log-stop`: permanently stops the log backup task. After executing this command, the Backup CR enters a stopped state and cannot be restarted. -These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. +These commands provide fine-grained control over the lifecycle of log backup tasks, enabling you to start, pause, resume, and stop tasks effectively to manage log data retention in Kubernetes environments. -In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. -However, you must not mix logStop with logSubcommand in the same Backup CR. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. +In TiDB Operator v1.5.4, v1.6.0, and earlier versions, you can use the `logStop: true/false` field to stop or start log backup tasks. This field is retained for backward compatibility. + +However, do not use `logStop` and `logSubcommand` fields in the same Backup CR, as this is not supported. For TiDB Operator v1.5.5, v1.6.1, and later versions, it is recommended to use the `logSubcommand` field to ensure clear and consistent configuration. + #### Start log backup @@ -181,6 +183,7 @@ However, you must not mix logStop with logSubcommand in the same Backup CR. Doin namespace: backup-test spec: backupMode: log + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 @@ -243,13 +246,13 @@ Log Checkpoint Ts: 436569119308644661 #### Pause log backup -Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. +You can pause a log backup task by setting the `logSubcommand` field of the Backup Custom Resource (CR) to `log-pause`. The following example shows how to pause the `demo1-log-backup-gcs` CR created in [Start log backup](#start-log-backup). ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: +To pause the log backup task, change the value of `logSubcommand` from `log-start` to `log-pause`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -272,7 +275,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Pause`: +You can verify that the `STATUS` of the `demo1-log-backup-gcs` Backup CR changes from `Running` to `Pause`: ```shell kubectl get backup -n backup-test @@ -285,13 +288,17 @@ demo1-log-backup-gcs log Pause .... #### Resume log backup -If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. +If a log backup task is paused, you can resume it by setting the `logSubcommand` field to `log-start`. The following example shows how to resume the `demo1-log-backup-gcs` CR that was paused in [Pause Log Backup](#pause-log-backup). + +> **Note:** +> +> This operation applies only to tasks in the `Pause` state. You cannot resume tasks in the `Fail` or `Stopped` state. ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: +To resume the log backup task, change the value of `logSubcommand` from `log-pause` to `log-start`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -314,7 +321,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Pause` to `Running`: +You can verify that the `STATUS` of the `demo1-log-backup-gcs` Backup CR changes from `Pause` to `Running`: ```shell kubectl get backup -n backup-test @@ -327,13 +334,13 @@ demo1-log-backup-gcs log Running .... #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. +You can stop a log backup task by setting the `logSubcommand` field of the Backup Custom Resource (CR) to `log-stop`. The following example shows how to stop the `demo1-log-backup-gcs` CR created in [Start log backup](#start-log-backup). ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: +Change the value of `logSubcommand` to `log-stop`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -356,7 +363,7 @@ spec: prefix: my-log-backup-folder ``` -You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Stopped`: +You can verify that the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` changes from `Running` to `Stopped`: ```shell kubectl get backup -n backup-test @@ -368,9 +375,11 @@ demo1-log-backup-gcs log Stopped .... ``` -Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. -In TiDB Operator versions earlier than v1.5.4/v1.6.0, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. +`Stopped` is the terminal state for log backup. In this state, you cannot change the backup state again, but you can still clean up the log backup data. + +In TiDB Operator v1.5.4, v1.6.0, and earlier versions, you can use the `logStop: true/false` field to stop or start log backup tasks. This field is retained for backward compatibility. + #### Clean log backup data diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 9f0e77a0d..f18691968 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -179,6 +179,7 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- namespace: backup-test spec: backupMode: log + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 @@ -255,25 +256,25 @@ kubectl apply -f log-backup-azblob.yaml 修改后 `log-backup-azblob.yaml` 文件内容如下： - ```yaml - --- - apiVersion: pingcap.com/v1alpha1 - kind: Backup - metadata: - name: demo1-log-backup-azblob - namespace: backup-test - spec: - backupMode: log - logSubcommand: log-pause - br: - cluster: demo1 - clusterNamespace: test1 - sendCredToTikv: true - azblob: - secretName: azblob-secret - container: my-container - prefix: my-log-backup-folder - ``` +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-azblob + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder +``` 可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： @@ -283,7 +284,7 @@ kubectl get backup -n backup-test ``` NAME MODE STATUS .... -demo1-log-backup-azblob log Pause .... +demo1-log-backup-azblob log Pause .... ``` #### 恢复日志备份 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 5343249a5..c5fc69999 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -183,6 +183,7 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac namespace: backup-test spec: backupMode: log + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 @@ -360,7 +361,6 @@ spec: secretName: gcs-secret bucket: my-bucket prefix: my-log-backup-folder - logStop: true ``` 可以看到名为 `demo1-log-backup-gcs` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Stopped`： @@ -375,9 +375,11 @@ demo1-log-backup-gcs log Stopped .... ``` + `Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + #### 清理日志备份数据 From b880ac53701db934a5e7d6b7996343e31fe5f362 Mon Sep 17 00:00:00 2001 From: RidRisR <79858083+RidRisR@users.noreply.github.com> Date: Mon, 20 Jan 2025 09:11:40 +0100 Subject: [PATCH 65/66] add chinese part --- zh/backup-restore-cr.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/zh/backup-restore-cr.md b/zh/backup-restore-cr.md index 5571bdca0..c74924c5d 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -39,6 +39,8 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `log-pause`：暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 * `log-stop`：永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 + 对于 v1.5.5 之前的版本，请使用布尔值变量（true/false） logStop 字段来控制日志备份操作。在 v1.5.5 和 v1.6.1 版本中，logStop 仍然受支持，但建议改用 logSubcommand。 + * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。 * `volume-snapshot`：基于卷快照的 TiDB 集群恢复。 From 1e98023fe07a0a1532ac8ffdc19ba0f82c441b92 Mon Sep 17 00:00:00 2001 From: Aolin Date: Mon, 20 Jan 2025 16:18:43 +0800 Subject: [PATCH 66/66] Apply suggestions from code review --- zh/backup-restore-cr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/backup-restore-cr.md b/zh/backup-restore-cr.md index c74924c5d..604d1de70 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -39,7 +39,7 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `log-pause`：暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 * `log-stop`：永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 - 对于 v1.5.5 之前的版本，请使用布尔值变量（true/false） logStop 字段来控制日志备份操作。在 v1.5.5 和 v1.6.1 版本中，logStop 仍然受支持，但建议改用 logSubcommand。 + 对于 v1.5.5 之前的版本，请使用 `logStop` 字段（布尔值 `true`/`false`）控制日志备份操作。虽然 v1.5.5 和 v1.6.1 版本仍支持 `logStop`，但建议使用 `logSubcommand`。 * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。