From 1afc96755e5c20a0a48d88457840de589b40315f Mon Sep 17 00:00:00 2001 From: Aolin Date: Thu, 27 Jun 2024 16:01:29 +0800 Subject: [PATCH 1/5] Small updates to TiKV config docs --- glossary.md | 4 ++++ tikv-configuration-file.md | 8 ++++---- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/glossary.md b/glossary.md index e5fe009cc7eac..031519e9d2c5b 100644 --- a/glossary.md +++ b/glossary.md @@ -75,6 +75,10 @@ Leader/Follower/Learner each corresponds to a role in a Raft group of [peers](#r Starting from v5.0, TiDB introduces Massively Parallel Processing (MPP) architecture through TiFlash nodes, which shares the execution workloads of large join queries among TiFlash nodes. When the MPP mode is enabled, TiDB, based on cost, determines whether to use the MPP framework to perform the calculation. In the MPP mode, the join keys are redistributed through the Exchange operation while being calculated, which distributes the calculation pressure to each TiFlash node and speeds up the calculation. For more information, see [Use TiFlash MPP Mode](/tiflash/use-tiflash-mpp-mode.md). +### Multi-version concurrency control (MVCC) + +[MVCC](https://en.wikipedia.org/wiki/Multiversion_concurrency_control) is a concurrency control mechanism in TiDB and other databases. It processes the memory read by transactions to achieve concurrent access to TiDB, thereby avoiding blocking caused by conflicts between concurrent reads and writes. + ## O ### Old value diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 069f21b80ba75..86d8000212277 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -464,9 +464,9 @@ Configuration items related to storage. > **Warning:** > > - Set `enable-ttl` to `true` or `false` **ONLY WHEN** deploying a new TiKV cluster. **DO NOT** modify the value of this configuration item in an existing TiKV cluster. TiKV clusters with different `enable-ttl` values use different data formats. Therefore, if you modify the value of this item in an existing TiKV cluster, the cluster will store data in different formats, which causes the "can't enable TTL on a non-ttl" error when you restart the TiKV cluster. -> - Use `enable-ttl` **ONLY IN** a TiKV cluster. **DO NOT** use this configuration item in a cluster that has TiDB nodes (which means setting `enable-ttl` to `true` in such clusters). Otherwise, critical issues such as data corruption and the upgrade failure of TiDB clusters will occur. +> - Use `enable-ttl` **ONLY IN** a TiKV cluster. **DO NOT** use this configuration item in a cluster that has TiDB nodes (which means setting `enable-ttl` to `true` in such clusters) unless `storage.api-version = 2` is configured. Otherwise, critical issues such as data corruption and the upgrade failure of TiDB clusters will occur. -+ TTL is short for "Time to live". If this item is enabled, TiKV automatically deletes data that reaches its TTL. To set the value of TTL, you need to specify it in the requests when writing data via the client. If the TTL is not specified, it means that TiKV does not automatically delete the corresponding data. ++ [TTL](/time-to-live.md) is short for "Time to live". If this item is enabled, TiKV automatically deletes data that reaches its TTL. To set the value of TTL, you need to specify it in the requests when writing data via the client. If the TTL is not specified, it means that TiKV does not automatically delete the corresponding data. + Default value: `false` ### `ttl-check-poll-interval` @@ -488,9 +488,9 @@ Configuration items related to storage. + Value options: + `1`: Uses API V1, does not encode the data passed from the client, and stores data as it is. In versions earlier than v6.1.0, TiKV uses API V1 by default. + `2`: Uses API V2: - + The data is stored in the Multi-Version Concurrency Control (MVCC) format, where the timestamp is obtained from PD (which is TSO) by tikv-server. + + The data is stored in the [Multi-Version Concurrency Control (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc) format, where the timestamp is obtained from PD (which is TSO) by tikv-server. + Data is scoped according to different usage and API V2 supports co-existence of TiDB, Transactional KV, and RawKV applications in a single cluster. - + When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on `enable-ttl` explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`. + + When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on [`enable-ttl`](#enable-ttl) explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`. + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim obsolete data. This tidb-server instance can provide read and write services at the same time. To ensure high availability, you can deploy multiple tidb-server instances. + Client support is required for API V2. For details, see the corresponding instruction of the client for the API V2. + Since v6.2.0, Change Data Capture (CDC) for RawKV is supported. Refer to [RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc). From 9e976aa59b81502ce9159e345a1c2d005480bec7 Mon Sep 17 00:00:00 2001 From: Aolin Date: Thu, 27 Jun 2024 15:55:54 +0800 Subject: [PATCH 2/5] Apply suggestions from code review --- tikv-configuration-file.md | 1 - 1 file changed, 1 deletion(-) diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 86d8000212277..d50d7ea3c58b1 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -489,7 +489,6 @@ Configuration items related to storage. + `1`: Uses API V1, does not encode the data passed from the client, and stores data as it is. In versions earlier than v6.1.0, TiKV uses API V1 by default. + `2`: Uses API V2: + The data is stored in the [Multi-Version Concurrency Control (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc) format, where the timestamp is obtained from PD (which is TSO) by tikv-server. - + Data is scoped according to different usage and API V2 supports co-existence of TiDB, Transactional KV, and RawKV applications in a single cluster. + When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on [`enable-ttl`](#enable-ttl) explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`. + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim obsolete data. This tidb-server instance can provide read and write services at the same time. To ensure high availability, you can deploy multiple tidb-server instances. + Client support is required for API V2. For details, see the corresponding instruction of the client for the API V2. From 964e7340d0f8ffef3cb7edd8c6ea22d369e1aee8 Mon Sep 17 00:00:00 2001 From: Aolin Date: Thu, 27 Jun 2024 15:56:12 +0800 Subject: [PATCH 3/5] Apply suggestions from code review --- tikv-configuration-file.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index d50d7ea3c58b1..186f4e07470c5 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -490,7 +490,7 @@ Configuration items related to storage. + `2`: Uses API V2: + The data is stored in the [Multi-Version Concurrency Control (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc) format, where the timestamp is obtained from PD (which is TSO) by tikv-server. + When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on [`enable-ttl`](#enable-ttl) explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`. - + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim obsolete data. This tidb-server instance can provide read and write services at the same time. To ensure high availability, you can deploy multiple tidb-server instances. + + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim expired data. Note that this tidb-server instance cannot provide read or write services. To ensure high availability, you can deploy multiple tidb-server instances. + Client support is required for API V2. For details, see the corresponding instruction of the client for the API V2. + Since v6.2.0, Change Data Capture (CDC) for RawKV is supported. Refer to [RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc). + Default value: `1` From 6ed686a70eec56e06a7ba72572330e2c39acb10b Mon Sep 17 00:00:00 2001 From: Aolin Date: Thu, 27 Jun 2024 16:03:30 +0800 Subject: [PATCH 4/5] Apply suggestions from code review --- tikv-configuration-file.md | 1 + 1 file changed, 1 insertion(+) diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 186f4e07470c5..08e116f52eeb1 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -489,6 +489,7 @@ Configuration items related to storage. + `1`: Uses API V1, does not encode the data passed from the client, and stores data as it is. In versions earlier than v6.1.0, TiKV uses API V1 by default. + `2`: Uses API V2: + The data is stored in the [Multi-Version Concurrency Control (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc) format, where the timestamp is obtained from PD (which is TSO) by tikv-server. + + Data is scoped according to different usage and API V2 supports co-existence of TiDB, Transactional KV, and RawKV applications in a single cluster. + When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on [`enable-ttl`](#enable-ttl) explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`. + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim expired data. Note that this tidb-server instance cannot provide read or write services. To ensure high availability, you can deploy multiple tidb-server instances. + Client support is required for API V2. For details, see the corresponding instruction of the client for the API V2. From 85546fe9b359b0cb2658b1aa92d1602e9339a242 Mon Sep 17 00:00:00 2001 From: Aolin Date: Thu, 27 Jun 2024 16:03:48 +0800 Subject: [PATCH 5/5] Apply suggestions from code review --- tikv-configuration-file.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 08e116f52eeb1..86d8000212277 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -491,7 +491,7 @@ Configuration items related to storage. + The data is stored in the [Multi-Version Concurrency Control (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc) format, where the timestamp is obtained from PD (which is TSO) by tikv-server. + Data is scoped according to different usage and API V2 supports co-existence of TiDB, Transactional KV, and RawKV applications in a single cluster. + When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on [`enable-ttl`](#enable-ttl) explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`. - + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim expired data. Note that this tidb-server instance cannot provide read or write services. To ensure high availability, you can deploy multiple tidb-server instances. + + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim obsolete data. This tidb-server instance can provide read and write services at the same time. To ensure high availability, you can deploy multiple tidb-server instances. + Client support is required for API V2. For details, see the corresponding instruction of the client for the API V2. + Since v6.2.0, Change Data Capture (CDC) for RawKV is supported. Refer to [RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc). + Default value: `1`