diff --git a/en/backup-restore-cr.md b/en/backup-restore-cr.md index 2408858fd..640a9e17e 100644 --- a/en/backup-restore-cr.md +++ b/en/backup-restore-cr.md @@ -36,6 +36,13 @@ 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 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. + + 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. * `volume-snapshot`: restore data from volume snapshots. diff --git a/en/backup-restore-overview.md b/en/backup-restore-overview.md index 4a68da17b..5923fd439 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 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. 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/en/backup-to-aws-s3-using-br.md b/en/backup-to-aws-s3-using-br.md index 24f0f5979..b2c3b9eec 100644 --- a/en/backup-to-aws-s3-using-br.md +++ b/en/backup-to-aws-s3-using-br.md @@ -228,6 +228,26 @@ 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. +#### Description of the `logSubcommand` field + +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`: 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. + +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 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 1. In the `backup-test` namespace, create a `Backup` CR named `demo1-log-backup-s3`. @@ -247,6 +267,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 +329,105 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +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, change the value of `logSubcommand` from `log-start` to `log-pause`, then save and exit 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 verify that the `STATUS` of the `demo1-log-backup-s3` Backup CR changes 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 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, 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-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 verify that the `STATUS` of the `demo1-log-backup-s3` Backup CR changes from `Pause` to `Running`: + +```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. +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 ``` -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 value of `logSubcommand` to `log-stop`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -327,6 +438,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -337,10 +449,9 @@ 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`: +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 @@ -352,12 +463,16 @@ 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 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 -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 @@ -374,6 +489,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/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 49a7cf8f7..08d9fb5b4 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -139,6 +139,26 @@ 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. +#### Description of the `logSubcommand` field + +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`: 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. + +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 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 1. In the `backup-test` namespace, create a `Backup` CR named `demo1-log-backup-azblob`. @@ -158,6 +178,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 +239,108 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +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 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 +``` + +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 +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-azblob log Pause .... +``` + +#### Resume log backup + +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 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 +``` + +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 +``` + +``` +NAME MODE STATUS .... +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. The priority of all operations is: stop log backup > delete log backup data > start log backup. +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 ``` -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 value of `logSubcommand` to `log-stop`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -237,6 +351,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -246,10 +361,9 @@ 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`: +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 @@ -261,12 +375,16 @@ 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 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 -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 +401,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..6c9e8e648 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -142,7 +142,27 @@ 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. + +#### Description of the `logSubcommand` field + +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`: 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. + +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 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 @@ -163,6 +183,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 @@ -223,15 +244,103 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +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, change the value of `logSubcommand` from `log-start` to `log-pause`, then save and exit 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 verify that the `STATUS` of the `demo1-log-backup-gcs` Backup CR changes 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 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, 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-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 verify that the `STATUS` of the `demo1-log-backup-gcs` Backup CR changes from `Pause` to `Running`: + +```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. +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 ``` -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 value of `logSubcommand` to `log-stop`, then save and exit the editor. The modified content is as follows: ```yaml --- @@ -242,6 +351,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -251,10 +361,9 @@ 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`: +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 @@ -266,12 +375,16 @@ 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 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 -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 +401,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/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/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 6ac9cea4c..604d1de70 100644 --- a/zh/backup-restore-cr.md +++ b/zh/backup-restore-cr.md @@ -34,6 +34,13 @@ summary: 介绍用于备份与恢复的 Custom Resource (CR) 资源的各字段 * `volume-snapshot`：基于卷快照的备份。 * `log`：从 KV 层备份实时数据变更日志数据。 +* `.spec.logSubcommand`：指定日志备份任务的子命令，用于控制日志备份任务的状态。该字段支持以下三个选项： + * `log-start`：启动一个新的日志备份任务，或恢复一个已暂停的任务。使用此命令可以开始日志备份流程，或从暂停状态恢复任务。 + * `log-pause`：暂停当前正在进行的日志备份任务。暂停任务后，你可以使用 `log-start` 命令恢复任务。 + * `log-stop`：永久停止日志备份任务。执行此命令后，Backup CR 会进入停止状态，且无法再次启动。 + + 对于 v1.5.5 之前的版本，请使用 `logStop` 字段（布尔值 `true`/`false`）控制日志备份操作。虽然 v1.5.5 和 v1.6.1 版本仍支持 `logStop`，但建议使用 `logSubcommand`。 + * `.spec.restoreMode`：指定 Restore 的模式，默认为 `snapshot`，即基于 KV 层的快照恢复。该字段仅在恢复时有效，目前支持以下三种类型： * `snapshot`：基于 KV 层的快照恢复。 * `volume-snapshot`：基于卷快照的 TiDB 集群恢复。 diff --git a/zh/backup-restore-overview.md b/zh/backup-restore-overview.md index d0f763f51..d59337547 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.5、v1.6.1 及之后的版本，当你删除 CR 时，TiDB Operator 会尝试自动停止正在运行的日志备份任务。此自动停止功能仅适用于正常运行的日志备份任务，不会处理出现错误或失败状态的任务。 + 如果你使用基于 AWS EBS 卷快照的备份，并将 `spec.cleanPolicy` 设置为 `Delete` 时，TiDB Operator 在删除 CR 以及清理备份文件的同时删除 AWS 上相关的所有卷快照。 在满足上述条件时，如果需要删除 namespace，建议首先删除所有的 Backup/BackupSchedule CR，再删除 namespace。 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index a6f95ea0d..a9c33aeca 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -225,6 +225,26 @@ 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 环境中的日志数据保留。 + + + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + +但是，请勿在同一个 Backup CR 中同时使用 `logStop` 和 `logSubcommand` 字段，这属于不支持的用法。对于 TiDB Operator v1.5.5、v1.6.1 及之后版本，推荐使用 `logSubcommand` 以确保配置清晰且一致。 + + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-s3` 的 `Backup` CR。 @@ -305,15 +325,105 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-pause` 来暂停日志备份任务。下面以暂停[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-s3` 的 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` 来恢复该任务。下面以恢复[暂停日志备份](#暂停日志备份)中已暂停的 `demo1-log-backup-s3` CR 为例。 + +> **Note:** +> +> 此操作仅适用于处于暂停状态 (`Pause`) 的任务，无法恢复状态为 `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-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-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 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-stop` 来停止日志备份。下面以停止[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-s3` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 `logSubcommand` 的值修改为 `log-stop`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -324,6 +434,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -334,7 +445,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`： @@ -349,12 +459,16 @@ demo1-log-backup-s3 log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 + +`Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `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 @@ -371,6 +485,7 @@ demo1-log-backup-s3 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-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 741626ad9..f18691968 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -140,6 +140,26 @@ 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 环境中的日志数据保留。 + + + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + +但是，请勿在同一个 Backup CR 中同时使用 `logStop` 和 `logSubcommand` 字段，这属于不支持的用法。对于 TiDB Operator v1.5.5、v1.6.1 及之后版本，推荐使用 `logSubcommand` 以确保配置清晰且一致。 + + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-azblob` 的 `Backup` CR。 @@ -159,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 @@ -219,15 +240,107 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-pause` 来暂停日志备份任务。下面以暂停[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-azblob` 的 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 + azblob: + secretName: azblob-secret + container: my-container + 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` 来恢复该任务。下面以恢复[暂停日志备份](#暂停日志备份)中已暂停的 `demo1-log-backup-azblob` CR 为例。 + +> **Note:** +> +> 此操作仅适用于处于暂停状态 (`Pause`) 的任务，无法恢复状态为 `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 + azblob: + secretName: azblob-secret + container: my-container + 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 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-stop` 来停止日志备份。下面以停止[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-azblob` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 `logSubcommand` 的值修改为 `log-stop`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -238,6 +351,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -247,7 +361,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 +375,16 @@ demo1-log-backup-azblob log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 + +`Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `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 +401,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..c5fc69999 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -144,6 +144,26 @@ 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 环境中的日志数据保留。 + + + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `logStop: true/false` 字段来停止或启动日志备份任务。此字段仍然保留以确保向后兼容。 + +但是，请勿在同一个 Backup CR 中同时使用 `logStop` 和 `logSubcommand` 字段，这属于不支持的用法。对于 TiDB Operator v1.5.5、v1.6.1 及之后版本，推荐使用 `logSubcommand` 以确保配置清晰且一致。 + + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-gcs` 的 `Backup` CR。 @@ -163,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 @@ -223,15 +244,103 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-pause` 来暂停日志备份任务。下面以暂停[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-gcs` 的 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` 来恢复该任务。下面以恢复[暂停日志备份](#暂停日志备份)中已暂停的 `demo1-log-backup-gcs` CR 为例。 + +> **Note:** +> +> 此操作仅适用于处于暂停状态 (`Pause`) 的任务，无法恢复状态为 `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 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +你可以通过将 Backup 自定义资源 (CR) 的 `logSubcommand` 字段设置为 `log-stop` 来停止日志备份。下面以停止[启动日志备份](#启动日志备份)中创建的名为 `demo1-log-backup-gcs` 的 CR 为例。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 `logSubcommand` 的值修改为 `log-stop`，然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -242,6 +351,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -251,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`： @@ -266,12 +375,16 @@ demo1-log-backup-gcs log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 + +`Stopped` 是日志备份的终止状态。在此状态下，无法再次更改备份状态，但你仍然可以清理日志备份数据。 + +在 TiDB Operator v1.5.4、v1.6.0 及之前版本中，可以使用 `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 +401,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 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 + 所包含的步骤如下：