Fix typos for .md files at root directory of pingcap/docs

CONTRIBUTING.md

@@ -44,7 +44,7 @@ Please check out these templates before you submit a pull request:
 We use separate branches to maintain different versions of TiDB documentation.
 
 - The [documentation under development](https://docs.pingcap.com/tidb/dev) is maintained in the `master` branch.
-- The [published documentation](https://docs.pingcap.com/tidb/stable/) is maintained in the corresponding `release-<verion>` branch. For example, TiDB v7.5 documentation is maintained in the `release-7.5` branch.
+- The [published documentation](https://docs.pingcap.com/tidb/stable/) is maintained in the corresponding `release-<version>` branch. For example, TiDB v7.5 documentation is maintained in the `release-7.5` branch.
 - The [archived documentation](https://docs-archive.pingcap.com/) is no longer maintained and does not receive any further updates.
 
 ### Use cherry-pick labels

best-practices-on-public-cloud.md

@@ -180,7 +180,7 @@ To reduce the number of Regions and alleviate the heartbeat overhead on the syst
 
 ## After tuning
 
-After the tunning, the following effects can be observed:
+After the tuning, the following effects can be observed:
 
 - The TSO requests per second are decreased to 64,800.
 - The CPU utilization is significantly reduced from approximately 4,600% to 1,400%.

check-before-deployment.md

@@ -269,7 +269,7 @@ To check whether the NTP service is installed and whether it synchronizes with t
         Unable to talk to NTP daemon. Is it running?
         ```
 
-3. Run the `chronyc tracking` command to check wheter the Chrony service synchronizes with the NTP server.
+3. Run the `chronyc tracking` command to check whether the Chrony service synchronizes with the NTP server.
 
     > **Note:**
     >

configure-memory-usage.md

@@ -57,7 +57,7 @@ Currently, the memory limit set by `tidb_server_memory_limit` **DOES NOT** termi
 >
 > + During the startup process, TiDB does not guarantee that the [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640) limit is enforced. If the free memory of the operating system is insufficient, TiDB might still encounter OOM. You need to ensure that the TiDB instance has enough available memory.
 > + In the process of memory control, the total memory usage of TiDB might slightly exceed the limit set by `tidb_server_memory_limit`.
-> + Since v6.5.0, the configruation item `server-memory-quota` is deprecated. To ensure compatibility, after you upgrade your cluster to v6.5.0 or a later version, `tidb_server_memory_limit` will inherit the value of `server-memory-quota`. If you have not configured `server-memory-quota` before the upgrade, the default value of `tidb_server_memory_limit` is used, which is `80%`.
+> + Since v6.5.0, the configuration item `server-memory-quota` is deprecated. To ensure compatibility, after you upgrade your cluster to v6.5.0 or a later version, `tidb_server_memory_limit` will inherit the value of `server-memory-quota`. If you have not configured `server-memory-quota` before the upgrade, the default value of `tidb_server_memory_limit` is used, which is `80%`.
 
 When the memory usage of a tidb-server instance reaches a certain proportion of the total memory (the proportion is controlled by the system variable [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)), tidb-server will try to trigger a Golang GC to relieve memory stress. To avoid frequent GCs that cause performance issues due to the instance memory fluctuating around the threshold, this GC method will trigger GC at most once every minute.
 

ddl-introduction.md

@@ -77,7 +77,7 @@ absent -> delete only -> write only -> write reorg -> public
 For users, the newly created index is unavailable before the `public` state.
 
 <SimpleTab>
-<div label="Online DDL asychronous change before TiDB v6.2.0">
+<div label="Online DDL asynchronous change before TiDB v6.2.0">
 
 Before v6.2.0, the process of handling asynchronous schema changes in the TiDB SQL layer is as follows:
 

encryption-at-rest.md

@@ -287,7 +287,7 @@ The encryption algorithm currently supported by TiFlash is consistent with that
 
 The same master key can be shared by multiple instances of TiFlash, and can also be shared among TiFlash and TiKV. The recommended way to provide a master key in production is via AWS KMS. Alternatively, if using custom key is desired, supplying the master key via file is also supported. The specific method to generate master key and the format of the master key are the same as TiKV.
 
-TiFlash uses the current data key to encrypt all data placed on the disk, including data files, Schmea files, and temporary data files generated during calculations. Data keys are automatically rotated by TiFlash every week by default, and the period is configurable. On key rotation, TiFlash does not rewrite all existing files to replace the key, but background compaction tasks are expected to rewrite old data into new data files, with the most recent data key, if the cluster gets constant write workload. TiFlash keeps track of the key and encryption method used to encrypt each of the files and use the information to decrypt the content on reads.
+TiFlash uses the current data key to encrypt all data placed on the disk, including data files, Schema files, and temporary data files generated during calculations. Data keys are automatically rotated by TiFlash every week by default, and the period is configurable. On key rotation, TiFlash does not rewrite all existing files to replace the key, but background compaction tasks are expected to rewrite old data into new data files, with the most recent data key, if the cluster gets constant write workload. TiFlash keeps track of the key and encryption method used to encrypt each of the files and use the information to decrypt the content on reads.
 
 ### Key creation
 

explain-index-merge.md

@@ -94,6 +94,6 @@ When using the intersection-type index merge to access tables, the optimizer can
 >
 > - If the optimizer can choose the single index scan method (other than full table scan) for a query plan, the optimizer will not automatically use index merge. For the optimizer to use index merge, you need to use the optimizer hint.
 >
-> - Index Merge is not supported in [tempoaray tables](/temporary-tables.md) for now.
+> - Index Merge is not supported in [temporary tables](/temporary-tables.md) for now.
 >
 > - The intersection-type index merge will not automatically be selected by the optimizer. You must specify the **table name and index name** using the [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-) hint for it to be selected.

grafana-pd-dashboard.md

@@ -78,7 +78,7 @@ The following is the description of PD Dashboard metrics items:
 - Store Write rate keys: The total written keys on each TiKV instance
 - Hot cache write entry number: The number of peers on each TiKV instance that are in the write hotspot statistics module
 - Selector events: The event count of Selector in the hotspot scheduling module
-- Direction of hotspot move leader: The direction of leader movement in the hotspot scheduling. The positive number means scheduling into the instance. The negtive number means scheduling out of the instance
+- Direction of hotspot move leader: The direction of leader movement in the hotspot scheduling. The positive number means scheduling into the instance. The negative number means scheduling out of the instance
 - Direction of hotspot move peer: The direction of peer movement in the hotspot scheduling. The positive number means scheduling into the instance. The negative number means scheduling out of the instance
 
 ![PD Dashboard - Hot write metrics](/media/pd-dashboard-hotwrite-v4.png)

migrate-small-mysql-to-tidb.md

@@ -137,8 +137,8 @@ To view the historical status of the migration task and other internal metrics,
 
 If you have deployed Prometheus, Alertmanager, and Grafana when deploying DM using TiUP, you can access Grafana using the IP address and port specified during the deployment. You can then select the DM dashboard to view DM-related monitoring metrics.
 
-- The log directory of DM-master: specified by the DM-master process parameter `--log-file`. If you have deployd DM using TiUP, the log directory is `/dm-deploy/dm-master-8261/log/` by default.
-- The log directory of DM-worker: specified by the DM-worker process parameter `--log-file`. If you have deployd DM using TiUP, the log directory is `/dm-deploy/dm-worker-8262/log/` by default.
+- The log directory of DM-master: specified by the DM-master process parameter `--log-file`. If you have deployed DM using TiUP, the log directory is `/dm-deploy/dm-master-8261/log/` by default.
+- The log directory of DM-worker: specified by the DM-worker process parameter `--log-file`. If you have deployed DM using TiUP, the log directory is `/dm-deploy/dm-worker-8262/log/` by default.
 
 ## What's next
 

migrate-with-pt-ghost.md

@@ -7,7 +7,7 @@ summary: Learn how to use DM to replicate incremental data from databases that u
 
 In production scenarios, table locking during DDL execution can block the reads from or writes to the database to a certain extent. Therefore, online DDL tools are often used to execute DDLs to minimize the impact on reads and writes. Common DDL tools are [gh-ost](https://github.com/github/gh-ost) and [pt-osc](https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html).
 
-When using DM to migrate data from MySQL to TiDB, you can enbale `online-ddl` to allow collaboration of DM and gh-ost or pt-osc.
+When using DM to migrate data from MySQL to TiDB, you can enable `online-ddl` to allow collaboration of DM and gh-ost or pt-osc.
 
 For the detailed replication instructions, refer to the following documents by scenarios:
 

online-unsafe-recovery.md

@@ -38,7 +38,7 @@ Before using Online Unsafe Recovery, make sure that the following requirements a
 
 ### Step 1. Specify the stores that cannot be recovered
 
-To trigger automatic recovery, use PD Control to execute [`unsafe remove-failed-stores <store_id>[,<store_id>,...]`](/pd-control.md#unsafe-remove-failed-stores-store-ids--show) and specify **all** the TiKV nodes that cannot be recovered, seperated by commas.
+To trigger automatic recovery, use PD Control to execute [`unsafe remove-failed-stores <store_id>[,<store_id>,...]`](/pd-control.md#unsafe-remove-failed-stores-store-ids--show) and specify **all** the TiKV nodes that cannot be recovered, separated by commas.
 
 {{< copyable "shell-regular" >}}
 
@@ -174,7 +174,7 @@ After the recovery is completed, the data and index might be inconsistent. Use t
 ADMIN CHECK TABLE table_name;
 ```
 
-If there are inconsistent indexes, you can fix the index inconsistency by renaming the old index, creating a new index, and then droping the old index.
+If there are inconsistent indexes, you can fix the index inconsistency by renaming the old index, creating a new index, and then dropping the old index.
 
 1. Rename the old index:
 

oracle-functions-to-tidb.md

@@ -65,13 +65,13 @@ TiDB distinguishes between `NULL` and an empty string `''`.
 Oracle supports reading and writing to the same table in an `INSERT` statement. For example:
 
 ```sql
-INSERT INTO table1 VALUES (feild1,(SELECT feild2 FROM table1 WHERE...))
+INSERT INTO table1 VALUES (field1,(SELECT field2 FROM table1 WHERE...))
 ```
 
 TiDB does not support reading and writing to the same table in a `INSERT` statement. For example:
 
 ```sql
-INSERT INTO table1 VALUES (feild1,(SELECT T.fields2 FROM table1 T WHERE...))
+INSERT INTO table1 VALUES (field1,(SELECT T.fields2 FROM table1 T WHERE...))
 ```
 
 ### Get the first n rows from a query

pd-configuration-file.md

@@ -481,7 +481,7 @@ Configuration items related to the [TiDB Dashboard](/dashboard/dashboard-intro.m
 
 Configuration items related to the replication mode of all Regions. See [Enable the DR Auto-Sync mode](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode) for details.
 
-## Controllor
+## Controller
 
 This section describes the configuration items that are built into PD for [Resource Control](/tidb-resource-control.md).
 

performance-tuning-methods.md

@@ -187,7 +187,7 @@ The number of `StmtPrepare` commands per second is much greater than that of `St
 
 ![OLTP-Query](/media/performance/prepared_statement_leaking.png)
 
-- In the QPS panel, the red bold line indicates the number of failed queries, and the Y axis on the right indicates the coordinate value of the number. In this example, the number of failed quries per second is 74.6.
+- In the QPS panel, the red bold line indicates the number of failed queries, and the Y axis on the right indicates the coordinate value of the number. In this example, the number of failed queries per second is 74.6.
 - In the CPS By Type panel, the number of `StmtPrepare` commands per second is much greater than that of `StmtClose` per second, which indicates that an object leak occurs in the application for prepared statements.
 - In the Queries Using Plan Cache OPS panel, `avg-miss` is almost equal to `StmtExecute` in the CPS By Type panel, which indicates that almost all SQL executions miss the execution plan cache.
 
@@ -256,7 +256,7 @@ The Duration panel contains the average and P99 latency of all statements, and t
 - in-txn: The interval between processing the previous SQL and receiving the next SQL statement when the connection is within a transaction.
 - not-in-txn: The interval between processing the previous SQL and receiving the next SQL statement when the connection is not within a transaction.
 
-An applications perform transactions with the same database connction. By comparing the average query latency with the connection idle duration, you can determine if TiDB is the bottleneck for overall system, or if user response time jitter is caused by TiDB.
+An applications perform transactions with the same database connection. By comparing the average query latency with the connection idle duration, you can determine if TiDB is the bottleneck for overall system, or if user response time jitter is caused by TiDB.
 
 - If the application workload is not read-only and contains transactions, by comparing the average query latency with `avg-in-txn`, you can determine the proportion in processing transactions inside and outside the database, and identify the bottleneck in user response time.
 - If the application workload is read-only or autocommit mode is on, you can compare the average query latency with `avg-not-in-txn`.

performance-tuning-overview.md

@@ -107,7 +107,7 @@ After identifying the bottleneck of a system through performance analysis, you c
 
 According to [Amdahl's Law](https://en.wikipedia.org/wiki/Amdahl%27s_law), the maximum gain from performance tuning depends on the percentage of the optimized part in the overall system. Therefore, you need to identify the system bottlenecks and the corresponding percentage based on the performance data, and then predict the gains after the bottleneck is resolved or optimized.
 
-Note that even if a solution can bring the greatest potential benefits by tunning the largest bottleneck, you still need to evaluate the risks and costs of this solution. For example:
+Note that even if a solution can bring the greatest potential benefits by tuning the largest bottleneck, you still need to evaluate the risks and costs of this solution. For example:
 
 - The most straightforward tuning objective solution for a resource-overloaded system is to expand its capacity, but in practice, the expansion solution might be too costly to be adopted.
 - When a slow query in a business module causes a slow response of the entire module, upgrading to a new version of the database can solve the slow query issue, but it might also affect modules that did not have this issue. Therefore, this solution might have a potentially high risk. A low-risk solution is to skip the database version upgrade and rewrite the existing slow queries for the current database version.

replicate-data-to-kafka.md

@@ -31,7 +31,7 @@ The preceding steps are performed in a lab environment. You can also deploy a cl
 
 2. Create a Kafka cluster.
 
-    - Lab environment: refer to [Apache Kakfa Quickstart](https://kafka.apache.org/quickstart) to start a Kafka cluster.
+    - Lab environment: refer to [Apache Kafka Quickstart](https://kafka.apache.org/quickstart) to start a Kafka cluster.
     - Production environment: refer to [Running Kafka in Production](https://docs.confluent.io/platform/current/kafka/deployment.html) to deploy a Kafka production cluster.
 
 3. (Optional) Create a Flink cluster.

security-compatibility-with-mysql.md

@@ -143,7 +143,7 @@ The support for TLS authentication is configured differently. For detailed infor
 
 ### `tidb_auth_token`
 
-`tidb_auth_token` is a passwordless authentication method based on [JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519). In v6.4.0, `tidb_auth_token` is only used for user authentication in TiDB Cloud. Starting from v6.5.0, you can also configure `tidb_auth_token` as a user authentication method for TiDB Self-Hosted. Different from password-based authentication methods such as `mysql_native_passsword` and `caching_sha2_password`, when you create users using `tidb_auth_token`, there is no need to set or store custom passwords. To log into TiDB, users only need to use a signed token instead of a password, which simplifies the authentication process and improves security.
+`tidb_auth_token` is a passwordless authentication method based on [JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519). In v6.4.0, `tidb_auth_token` is only used for user authentication in TiDB Cloud. Starting from v6.5.0, you can also configure `tidb_auth_token` as a user authentication method for TiDB Self-Hosted. Different from password-based authentication methods such as `mysql_native_password` and `caching_sha2_password`, when you create users using `tidb_auth_token`, there is no need to set or store custom passwords. To log into TiDB, users only need to use a signed token instead of a password, which simplifies the authentication process and improves security.
 
 #### JWT
 

sql-plan-replayer.md

@@ -31,7 +31,7 @@ Based on `sql-statement`, TiDB sorts out and exports the following on-site infor
 - The table schema in `sql-statement`
 - The statistics of the table in `sql-statement`
 - The result of `EXPLAIN [ANALYZE] sql-statement`
-- Some internal procudures of query optimization
+- Some internal procedures of query optimization
 
 If historical statistics are [enabled](/system-variables.md#tidb_enable_historical_stats), you can specify a time in the `PLAN REPLAYER` statement to get the historical statistics for the corresponding time. You can directly specify a time and date or specify a timestamp. TiDB looks for the historical statistics before the specified time and exports the latest one among them.
 

system-variables.md

@@ -5232,10 +5232,10 @@ Query OK, 0 rows affected, 1 warning (0.00 sec)
 - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
 - Type: Boolean
 - Default value: `ON`
-- When accesing a partitioned table in [dynamic pruning mode](/partitioned-table.md#dynamic-pruning-mode), TiDB aggregates the statistics of each partition to generate GlobalStats. This variable controls the generation of GlobalStats when partition statistics are missing.
+- When accessing a partitioned table in [dynamic pruning mode](/partitioned-table.md#dynamic-pruning-mode), TiDB aggregates the statistics of each partition to generate GlobalStats. This variable controls the generation of GlobalStats when partition statistics are missing.
 
     - If this variable is `ON`, TiDB skips missing partition statistics when generating GlobalStats so the generation of GlobalStats is not affected.
-    - If this variable is `OFF`, TiDB stops generating GloablStats when it detects any missing partition statistics.
+    - If this variable is `OFF`, TiDB stops generating GlobalStats when it detects any missing partition statistics.
 
 ### tidb_skip_utf8_check