From 930eed947db86795e53d42cba3e6cdaf8f8baa89 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 26 May 2026 11:26:22 +0900 Subject: [PATCH 1/4] docs: improve HTAP terminology by changing 'storage links' to 'data pipelines' --- best-practices/tidb-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index a59395b85c770..12b65c1a12e47 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -215,4 +215,4 @@ TiDB is suitable for the following scenarios: - You do not want to do sharding - The access mode has no obvious hotspot - Transactions, strong consistency, and disaster recovery are required -- You hope to have real-time Hybrid Transaction/Analytical Processing (HTAP) analytics and reduce storage links +- You hope to have real-time Hybrid Transaction/Analytical Processing (HTAP) analytics and reduce data pipelines From 0e6eab7e75023528af8fef92ae8ffdb79be8ae42 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 26 May 2026 13:26:05 +0900 Subject: [PATCH 2/4] docs: improve terminology for indexes and PR background --- best-practices/tidb-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 12b65c1a12e47..7630146c13ac7 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -87,7 +87,7 @@ Lots of MySQL experience is also applicable to TiDB. It is noted that TiDB has i * The more secondary indexes, the better? - Secondary indexes can speed up queries, but adding an index has side effects. The previous section introduces the storage model of indexes. For each additional index, there will be one more Key-Value when inserting a row. Therefore, the more indexes, the slower the writing speed and the more space it takes up. + Secondary indexes can speed up queries, but adding an index has side effects. The previous section introduces the storage format of indexes. For each additional index, there will be one more Key-Value when inserting a row. Therefore, the more indexes, the slower the writing speed and the more space it takes up. In addition, too many indexes affects the runtime of the optimizer, and inappropriate indexes mislead the optimizer. Thus, more secondary indexes does not mean better performance. From 45f20820033ecc8c30def37d3f4e1bf2a9c46d7a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 26 May 2026 14:26:17 +0900 Subject: [PATCH 3/4] docs: improve terminology by changing 'region re-election' to 'region leader re-election' --- br/br-log-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index 3429e736b1092..f8faab666b45a 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -53,7 +53,7 @@ System components and key concepts involved in the log backup process: * **local checkpoint ts** (in local metadata): indicates that all logs generated before local checkpoint ts in this TiKV node have been backed up to the target storage. * **global checkpoint ts**: indicates that all logs generated before global checkpoint ts in all TiKV nodes have been backed up to the target storage. TiDB Coordinator calculates this timestamp by collecting local checkpoint ts of all TiKV node and then reports it to PD. * **TiDB Coordinator**: a TiDB node is elected as the coordinator, which is responsible for collecting and calculating the progress of the entire log backup task (global checkpoint ts). This component is stateless in design, and after its failure, a new Coordinator is elected from the surviving TiDB nodes. -* **TiKV log backup observer**: runs on each TiKV node in the TiDB cluster, which is responsible for backing up log data. If a TiKV node fails, backing up the data range on it will be taken by other TiKV nodes after region re-election, and these nodes will back up data of the failure range starting from global checkpoint ts. +* **TiKV log backup observer**: runs on each TiKV node in the TiDB cluster, which is responsible for backing up log data. If a TiKV node fails, backing up the data range on it will be taken by other TiKV nodes after region leader re-election, and these nodes will back up data of the failure range starting from global checkpoint ts. The complete backup process is as follows: From 1ae90a1912e673fec863e62a1345b3f6967751f2 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 26 May 2026 15:26:34 +0800 Subject: [PATCH 4/4] Update br/br-log-architecture.md --- br/br-log-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index f8faab666b45a..cfdfe3757a543 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -53,7 +53,7 @@ System components and key concepts involved in the log backup process: * **local checkpoint ts** (in local metadata): indicates that all logs generated before local checkpoint ts in this TiKV node have been backed up to the target storage. * **global checkpoint ts**: indicates that all logs generated before global checkpoint ts in all TiKV nodes have been backed up to the target storage. TiDB Coordinator calculates this timestamp by collecting local checkpoint ts of all TiKV node and then reports it to PD. * **TiDB Coordinator**: a TiDB node is elected as the coordinator, which is responsible for collecting and calculating the progress of the entire log backup task (global checkpoint ts). This component is stateless in design, and after its failure, a new Coordinator is elected from the surviving TiDB nodes. -* **TiKV log backup observer**: runs on each TiKV node in the TiDB cluster, which is responsible for backing up log data. If a TiKV node fails, backing up the data range on it will be taken by other TiKV nodes after region leader re-election, and these nodes will back up data of the failure range starting from global checkpoint ts. +* **TiKV log backup observer**: runs on each TiKV node in the TiDB cluster, which is responsible for backing up log data. If a TiKV node fails, backing up the data range on it will be taken by other TiKV nodes after Region leader re-election, and these nodes will back up data of the failure range starting from global checkpoint ts. The complete backup process is as follows: