for save

Author: Oreoxmt

command-line-flags-for-pd-configuration.md

@@ -110,7 +110,7 @@ PD is configurable using command-line flags and environment variables.
 
 - Force to create a new cluster using current nodes.
 - Default: `false`
-- It is recommended to use this flag only when recovering services due to PD loses most of the data, which might cause data loss.
+- It is recommended to use this flag only when recovering services due to PD losing most replicas, which might cause data loss.
 
 ## `-V`, `--version`
 

tikv-control.md

@@ -463,6 +463,26 @@ success!
 > - The argument of the `-p` option specifies the PD endpoints without the `http` prefix. Specifying the PD endpoints is to query whether the specified `region_id` is validated or not.
 > - You need to run this command for all stores where specified Regions' peers are located.
 
+### Recover from ACID inconsistency data
+
+To recover data from ACID inconsistency, such as the loss of most replicas or incomplete data synchronization, you can use the `reset-to-version` command. When using this command, you need to provide an old version number that can promise the ACID consistency. Then, `tikv-ctl` cleans up all data after the specified version.
+
+- The `-v` option is used to specify the version number to restore. To get the value of the `-v` parameter, you can use the `pd-ctl min-resolved-ts` command.
+
+```shell
+tikv-ctl --host 127.0.0.1:20160 reset-to-version -v 430315739761082369
+```
+
+```
+success!
+```
+
+> **Note:**
+>
+> - The preceding command only supports the online mode. Before executing the command, you need to stop processes that will write data to TiKV, such as TiDB. After the command is executed successfully, it will return `success!`.
+> - You need to execute the same command for all TiKV nodes in the cluster.
+> - All PD scheduling tasks should be stopped before executing the command.
+
 ### Ldb Command
 
 The `ldb` command line tool offers multiple data access and database administration commands. Some examples are listed below. For more information, refer to the help message displayed when running `tikv-ctl ldb` or check the documents from RocksDB.
@@ -580,23 +600,3 @@ From the output above, you can see that the information of the damaged SST file
 + In the `sst meta` part, `14` means the SST file number; `552997` means the file size, followed by the smallest and largest sequence numbers and other meta-information.
 + The `overlap region` part shows the information of the Region involved. This information is obtained through the PD server.
 + The `suggested operations` part provides you suggestion to clean up the damaged SST file. You can take the suggestion to clean up files and restart the TiKV instance.
-
-### Recover ACID inconsistency data
-
-On the cluster, if there are problems such as data loss of most replicas or incomplete data synchronization, resulting in data containing incomplete transactions, you can use the `reset-to-version`command to recover data with inconsistent ACID. At this time, you need to provide an old version number that guarantees ACID consistency and then `tikv-ctl` erases all data after this version.
-
-- The `-v` option is used to specify the version number to restore. To obtain the `-v` parameter, you can use the `pd-ctl min-resolved-ts`.
-
-```shell
-tikv-ctl --host 127.0.0.1:20160 reset-to-version -v 430315739761082369
-```
-
-```
-success!
-```
-
-> **Note:**
->
-> - This command only supports online mode. Before executing the command, you need to stop processes such as TiDB that will write data to TiKV. After the command is executed successfully, it will return `success!`.
-> - You need to execute the same command for all TiKV nodes in the cluster.
-> - All scheduling of the PD should be stopped before the command.

two-data-centers-in-one-city-deployment.md

@@ -273,32 +273,32 @@ The details for the status switch are as follows:
 
 ### Disaster recovery
 
-This section introduces the disaster recovery solution of the two data centers in one city deployment. The disaster discussed in this section is the overall failure of the primary data center, or the multiple TiKV nodes in the primary/secondary data center fail, resulting in the loss of most replicas and it is unable to provide services.
+This section introduces the disaster recovery solution of the two data centers in one city deployment. The disaster discussed in this section is the overall failure of the primary data center, or multiple TiKV nodes in the primary/secondary data center fail, resulting in the loss of most replicas and it is unable to provide services.
 
 #### Overall failure of the primary data center
 
-In this situation, all Regions in the primary data center have lost most of their replicas, so the cluster is unable to use. At this time, it is necessary to use the secondary data center to recover the service. The recovery ability is determined by the replication status before failure:
+In this situation, all Regions in the primary data center have lost most of their replicas, so the cluster is unable to use. At this time, it is necessary to use the secondary data center to recover the service. The replication status before failure determines the recovery ability:
 
 - If the status before failure is in the synchronous replication mode (the status code is `sync` or `async_wait`), you can use the secondary data center to recover using `RPO = 0`.
 
-- If the status before failure is in the asynchronous replication mode (the status code is `async`), the written data in the primary data center in the asynchronous replication mode is lost after using the secondary data center to recover. A typical scenario is that the primary cluster disconnects with the secondary cluster and the primary cluster switches to the asynchronous replication mode and provides service for a period of time before overall failure.
+- If the status before failure is in the asynchronous replication mode (the status code is `async`), the written data in the primary data center in the asynchronous replication mode is lost after using the secondary data center to recover. A typical scenario is that the primary data center disconnects from the secondary data center and the primary data center switches to the asynchronous replication mode and provides service for a while before the overall failure.
 
-- If the status before failure is switching from the asynchronous to synchronous (the status code is `sync-recover`), part of the written data in the primary data center in the asynchronous replication mode is lost after using the secondary data center to recover . This might cause the ACID inconsistency, and you need to recover ACID consistency additionally. A typical scenario is that the the primary cluster disconnects with the secondary cluster, the connection is restored after switching to asynchronous mode and data is written. But during the data synchronization between primary and secondary, something goes wrong and causes overall failure of the primary data center.
+- If the status before failure is switching from the asynchronous to synchronous (the status code is `sync-recover`), part of the written data in the primary data center in the asynchronous replication mode is lost after using the secondary data center to recover. This might cause the ACID inconsistency, and you need to recover it additionally. A typical scenario is that the primary data center disconnects from the secondary data center, the connection is restored after switching to the asynchronous mode, and data is written. But during the data synchronization between primary and secondary, something goes wrong and causes the overall failure of the primary data center.
 
 The process of disaster recovery is as follows:
 
-1. Stop all PD, TiKV and TiDB services of the secondary data center.
+1. Stop all PD, TiKV, and TiDB services of the secondary data center.
 
-2. Start PD nodes of the secondary data center using a replica mode with the [`--force-new-cluster`](/command-line-flags-for-pd-configuration.md#--force-new-cluster) flag.
+2. Start PD nodes of the secondary data center using the single replica mode with the [`--force-new-cluster`](/command-line-flags-for-pd-configuration.md#--force-new-cluster) flag.
 
-3. Use [Online Unsafe Recovery](/online-unsafe-recovery.md) to process the TiKV data in the secondary data center and the parameters are the list of all Store IDs in the primary data center.
+3. Use the [Online Unsafe Recovery](/online-unsafe-recovery.md) to process the TiKV data in the secondary data center and the parameters are the list of all Store IDs in the primary data center.
 
-4. Write a new placement rule configuration using [PD Control](/pd-control.md), and the Voter replica configuration of the Region is the same as the original cluster in the secondary data center.
+4. Write a new configuration of placement rule using [PD Control](/pd-control.md), and the Voter replica configuration of the Region is the same as the original cluster in the secondary data center.
 
-5. Start the PD and TiKV services of the primary cluster.
+5. Start the PD and TiKV services of the primary data center.
 
-6. To recover ACID consistency (the status of `DR_STATE` in the old PD is `sync-recover`), you can use [`reset-to-version`](/tikv-control.md#recover-acid-inconsistency-data) to process TiKV data and the `version` parameter used can be obtained from `pd-ctl min-resolved-ts`.
+6. To recover ACID consistency (the status of `DR_STATE` in the old PD is `sync-recover`), you can use [`reset-to-version`](/tikv-control.md#recover-from-acid-inconsistency-data) to process TiKV data and the `version` parameter used can be obtained from `pd-ctl min-resolved-ts`.
 
-7. Start the TiDB service in the primary cluster and check the data integrity and consistency.
+7. Start the TiDB service in the primary data center and check the data integrity and consistency.
 
-If you need a support for disaster recovery, you can contact the TiDB team for a recovery solution.
+If you need support for disaster recovery, you can contact the TiDB team for a recovery solution.