diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index a7ea8077a9caa..d935559cbf4fa 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -248,7 +248,7 @@ Hot regions scheduling issues generally fall into the following categories: - The load of some nodes is significantly higher than that of other nodes from TiKV-related metrics, which becomes the bottleneck of the whole system. Currently, PD counts hotspots through traffic analysis only, so it is possible that PD fails to identify hotspots in certain scenarios. For example, when there are intensive point lookup requests for some regions, it might not be obvious to detect in traffic, but still the high QPS might lead to bottlenecks in key modules. - **Solutions**: Firstly, locate the table where hot regions are formed based on the specific business. Then add a `scatter-range-scheduler` scheduler to make all regions of this table evenly distributed. TiDB also provides an interface in its HTTP API to simplify this operation. Refer to [TiDB HTTP API](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md) for more details. + **Solutions**: Firstly, locate the table where hot regions are formed based on the specific business. Then add a `scatter-range-scheduler` scheduler to make all regions of this table evenly distributed. TiDB also provides an interface in its HTTP API to simplify this operation. Refer to [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-4.0/docs/tidb_http_api.md) for more details. ### Region merge is slow diff --git a/information-schema/information-schema-cluster-info.md b/information-schema/information-schema-cluster-info.md index afac03abadeef..6534e8d2c16fc 100644 --- a/information-schema/information-schema-cluster-info.md +++ b/information-schema/information-schema-cluster-info.md @@ -34,7 +34,7 @@ Field description: * `TYPE`: The instance type. The optional values are `tidb`, `pd`, and `tikv`. * `INSTANCE`: The instance address, which is a string in the format of `IP:PORT`. -* `STATUS_ADDRESS`: The service address of HTTP API. Some commands in tikv-ctl, pd-ctl, or tidb-ctl might use this API and this address. You can also get more cluster information via this address. Refer to [TiDB HTTP API document](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md) for details. +* `STATUS_ADDRESS`: The service address of HTTP API. Some commands in tikv-ctl, pd-ctl, or tidb-ctl might use this API and this address. You can also get more cluster information via this address. Refer to [TiDB HTTP API document](https://github.com/pingcap/tidb/blob/release-4.0/docs/tidb_http_api.md) for details. * `VERSION`: The semantic version number of the corresponding instance. To be compatible with the MySQL version number, the TiDB version is displayed in the format of `${mysql-version}-${tidb-version}`. * `GIT_HASH`: The Git Commit Hash when compiling the instance version, which is used to identify whether two instances are of the absolutely consistent version. * `START_TIME`: The starting time of the corresponding instance. diff --git a/pd-configuration-file.md b/pd-configuration-file.md index b4662f014312e..7b00f3823e5f8 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -8,7 +8,7 @@ aliases: ['/docs/stable/pd-configuration-file/','/docs/v4.0/pd-configuration-fil -The PD configuration file supports more options than command-line parameters. You can find the default configuration file [here](https://github.com/pingcap/pd/blob/master/conf/config.toml). +The PD configuration file supports more options than command-line parameters. You can find the default configuration file [here](https://github.com/tikv/pd/blob/release-4.0/conf/config.toml). This document only describes parameters that are not included in command-line parameters. Check [here](/command-line-flags-for-pd-configuration.md) for the command line parameters. diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index a1c2c6f9e5386..9e282a1c4dad2 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -114,7 +114,7 @@ The following topology documents provide a cluster configuration template for ea > - For parameters that should be globally effective, configure these parameters of corresponding components in the `server_configs` section of the configuration file. > - For parameters that should be effective on a specific node, configure these parameters in the `config` of this node. > - Use `.` to indicate the subcategory of the configuration, such as `log.slow-threshold`. For more formats, see [TiUP configuration template](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/topology.example.yaml). -> - For more parameter description, see [TiDB `config.toml.example`](https://github.com/pingcap/tidb/blob/master/config/config.toml.example), [TiKV `config.toml.example`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml), [PD `config.toml.example`](https://github.com/pingcap/pd/blob/master/conf/config.toml), and [TiFlash configuration](/tiflash/tiflash-configuration.md). +> - For more parameter description, see [TiDB `config.toml.example`](https://github.com/pingcap/tidb/blob/release-4.0/config/config.toml.example), [TiKV `config.toml.example`](https://github.com/tikv/tikv/blob/release-4.0/etc/config-template.toml), [PD `config.toml.example`](https://github.com/tikv/pd/blob/release-4.0/conf/config.toml), and [TiFlash configuration](/tiflash/tiflash-configuration.md). ## Step 4: Execute the deployment command diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md index 9c8fc0b366d9c..16059d8df4f2d 100644 --- a/sync-diff-inspector/sync-diff-inspector-overview.md +++ b/sync-diff-inspector/sync-diff-inspector-overview.md @@ -6,7 +6,7 @@ aliases: ['/docs/stable/sync-diff-inspector/sync-diff-inspector-overview/','/doc # sync-diff-inspector User Guide -[sync-diff-inspector](https://github.com/pingcap/tidb-tools/tree/master/sync_diff_inspector) is a tool used to compare data stored in the databases with the MySQL protocol. For example, it can compare the data in MySQL with that in TiDB, the data in MySQL with that in MySQL, or the data in TiDB with that in TiDB. In addition, you can also use this tool to repair data in the scenario where a small amount of data is inconsistent. +[sync-diff-inspector](https://github.com/pingcap/tidb-tools/tree/release-4.0/sync_diff_inspector) is a tool used to compare data stored in the databases with the MySQL protocol. For example, it can compare the data in MySQL with that in TiDB, the data in MySQL with that in MySQL, or the data in TiDB with that in TiDB. In addition, you can also use this tool to repair data in the scenario where a small amount of data is inconsistent. This guide introduces the key features of sync-diff-inspector and describes how to configure and use this tool. You can download it at [tidb-enterprise-tools-nightly-linux-amd64](https://download.pingcap.org/tidb-enterprise-tools-nightly-linux-amd64.tar.gz). diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md index 4cd8634cd050b..1a5c37ac37af9 100644 --- a/ticdc/ticdc-open-protocol.md +++ b/ticdc/ticdc-open-protocol.md @@ -274,8 +274,8 @@ COMMIT; Currently, TiCDC does not provide the standard parsing library for TiCDC Open Protocol, but the Golang version and Java version of parsing demonstrations are provided. You can refer to the data format provided in this document and the following demonstrations to implement the protocol parsing for consumers. -- [Golang demo](https://github.com/pingcap/ticdc/tree/master/kafka_consumer) -- [Java demo](https://github.com/pingcap/ticdc/tree/master/demo/java) +- [Golang demo](https://github.com/pingcap/ticdc/tree/release-4.0/kafka_consumer) +- [Java demo](https://github.com/pingcap/ticdc/tree/release-4.0/demo/java) ## Column type code diff --git a/tidb-binlog/binlog-consumer-client.md b/tidb-binlog/binlog-consumer-client.md index 34ec3a6395b97..bd6804d4e2a37 100644 --- a/tidb-binlog/binlog-consumer-client.md +++ b/tidb-binlog/binlog-consumer-client.md @@ -118,11 +118,11 @@ message Binlog { } ``` -For the definition of the data format, see [`binlog.proto`](https://github.com/pingcap/tidb-tools/blob/master/tidb-binlog/proto/proto/binlog.proto). +For the definition of the data format, see [`binlog.proto`](https://github.com/pingcap/tidb-tools/blob/release-4.0/tidb-binlog/proto/proto/binlog.proto). ### Driver -The [TiDB-Tools](https://github.com/pingcap/tidb-tools/) project provides [Driver](https://github.com/pingcap/tidb-tools/tree/master/tidb-binlog/driver), which is used to read the binlog data in Kafka. It has the following features: +The [TiDB-Tools](https://github.com/pingcap/tidb-tools/) project provides [Driver](https://github.com/pingcap/tidb-tools/tree/release-4.0/tidb-binlog/driver), which is used to read the binlog data in Kafka. It has the following features: * Read the Kafka data. * Locate the binlog stored in Kafka based on `commit ts`. diff --git a/tidb-binlog/binlog-control.md b/tidb-binlog/binlog-control.md index f54521451fb60..6f1b71a1bfb3d 100644 --- a/tidb-binlog/binlog-control.md +++ b/tidb-binlog/binlog-control.md @@ -6,7 +6,7 @@ aliases: ['/docs/stable/tidb-binlog/binlog-control/','/docs/v4.0/tidb-binlog/bin # binlogctl -[Binlog Control](https://github.com/pingcap/tidb-binlog/tree/master/binlogctl) (`binlogctl` for short) is a command line tool for TiDB Binlog. You can use `binlogctl` to manage TiDB Binlog clusters. +[Binlog Control](https://github.com/pingcap/tidb-binlog/tree/release-4.0/binlogctl) (`binlogctl` for short) is a command line tool for TiDB Binlog. You can use `binlogctl` to manage TiDB Binlog clusters. You can use `binlogctl` to: diff --git a/tidb-binlog/maintain-tidb-binlog-cluster.md b/tidb-binlog/maintain-tidb-binlog-cluster.md index f9a936d3518e4..26fae5ae2d735 100644 --- a/tidb-binlog/maintain-tidb-binlog-cluster.md +++ b/tidb-binlog/maintain-tidb-binlog-cluster.md @@ -46,7 +46,7 @@ For how to pause, close, check, and modify the state of Drainer, see the [binlog ## Use `binlogctl` to manage Pump/Drainer -[`binlogctl`](https://github.com/pingcap/tidb-binlog/tree/master/binlogctl) is an operations tool for TiDB Binlog with the following features: +[`binlogctl`](https://github.com/pingcap/tidb-binlog/tree/release-4.0/binlogctl) is an operations tool for TiDB Binlog with the following features: * Checking the state of Pump or Drainer * Pausing or closing Pump or Drainer diff --git a/tidb-binlog/tidb-binlog-overview.md b/tidb-binlog/tidb-binlog-overview.md index b1adfef445099..1f9dee58a5f16 100644 --- a/tidb-binlog/tidb-binlog-overview.md +++ b/tidb-binlog/tidb-binlog-overview.md @@ -25,15 +25,15 @@ The TiDB Binlog cluster is composed of Pump and Drainer. ### Pump -[Pump](https://github.com/pingcap/tidb-binlog/blob/master/pump) is used to record the binlogs generated in TiDB, sort the binlogs based on the commit time of the transaction, and send binlogs to Drainer for consumption. +[Pump](https://github.com/pingcap/tidb-binlog/blob/release-4.0/pump) is used to record the binlogs generated in TiDB, sort the binlogs based on the commit time of the transaction, and send binlogs to Drainer for consumption. ### Drainer -[Drainer](https://github.com/pingcap/tidb-binlog/tree/master/drainer) collects and merges binlogs from each Pump, converts the binlog to SQL or data of a specific format, and replicates the data to a specific downstream platform. +[Drainer](https://github.com/pingcap/tidb-binlog/tree/release-4.0/drainer) collects and merges binlogs from each Pump, converts the binlog to SQL or data of a specific format, and replicates the data to a specific downstream platform. ### `binlogctl` guide -[`binlogctl`](https://github.com/pingcap/tidb-binlog/tree/master/binlogctl) is an operations tool for TiDB Binlog with the following features: +[`binlogctl`](https://github.com/pingcap/tidb-binlog/tree/release-4.0/binlogctl) is an operations tool for TiDB Binlog with the following features: * Obtaining the current `tso` of TiDB cluster * Checking the Pump/Drainer state @@ -56,7 +56,7 @@ The TiDB Binlog cluster is composed of Pump and Drainer. * Drainer supports replicating binlogs to MySQL, TiDB, Kafka or local files. If you need to replicate binlogs to other Drainer unsuppored destinations, you can set Drainer to replicate the binlog to Kafka and read the data in Kafka for customized processing according to binlog consumer protocol. See [Binlog Consumer Client User Guide](/tidb-binlog/binlog-consumer-client.md). -* To use TiDB Binlog for recovering incremental data, set the config `db-type` to `file` (local files in the proto buffer format). Drainer converts the binlog to data in the specified [proto buffer format](https://github.com/pingcap/tidb-binlog/blob/master/proto/binlog.proto) and writes the data to local files. In this way, you can use [Reparo](/tidb-binlog/tidb-binlog-reparo.md) to recover data incrementally. +* To use TiDB Binlog for recovering incremental data, set the config `db-type` to `file` (local files in the proto buffer format). Drainer converts the binlog to data in the specified [proto buffer format](https://github.com/pingcap/tidb-binlog/blob/release-4.0/proto/binlog.proto) and writes the data to local files. In this way, you can use [Reparo](/tidb-binlog/tidb-binlog-reparo.md) to recover data incrementally. Pay attention to the value of `db-type`: diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index acc9421ccd4e0..5cde704a1d54e 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -9,7 +9,7 @@ aliases: ['/docs/stable/tidb-configuration-file/','/docs/v4.0/tidb-configuration # TiDB Configuration File -The TiDB configuration file supports more options than command-line parameters. You can download the default configuration file [`config.toml.example`](https://github.com/pingcap/tidb/blob/master/config/config.toml.example) and rename it to `config.toml`. This document describes only the options that are not involved in [command line options](/command-line-flags-for-tidb-configuration.md). +The TiDB configuration file supports more options than command-line parameters. You can download the default configuration file [`config.toml.example`](https://github.com/pingcap/tidb/blob/release-4.0/config/config.toml.example) and rename it to `config.toml`. This document describes only the options that are not involved in [command line options](/command-line-flags-for-tidb-configuration.md). ### `split-table` diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 36cde677a214c..4cc5d26e9cbc5 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -67,7 +67,7 @@ Scheduling is based on information collection. In short, the PD scheduling compo - State information reported by each TiKV peer: - Each TiKV peer sends heartbeats to PD periodically. PD not only checks whether the store is alive, but also collects [`StoreState`](https://github.com/pingcap/kvproto/blob/release-3.1/proto/pdpb.proto#L421) in the heartbeat message. `StoreState` includes: + Each TiKV peer sends heartbeats to PD periodically. PD not only checks whether the store is alive, but also collects [`StoreState`](https://github.com/pingcap/kvproto/blob/release-4.0/proto/pdpb.proto#L435) in the heartbeat message. `StoreState` includes: * Total disk space * Available disk space @@ -79,7 +79,7 @@ Scheduling is based on information collection. In short, the PD scheduling compo - Information reported by Region leaders: - Each Region leader sends heartbeats to PD periodically to report [`RegionState`](https://github.com/pingcap/kvproto/blob/release-3.1/proto/pdpb.proto#L271), including: + Each Region leader sends heartbeats to PD periodically to report [`RegionState`](https://github.com/pingcap/kvproto/blob/release-4.0/proto/pdpb.proto#L284), including: * Position of the leader itself * Positions of other replicas diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index cbab7f69ceeba..d2e1621079978 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -8,7 +8,7 @@ aliases: ['/docs/stable/tikv-configuration-file/','/docs/v4.0/tikv-configuration -The TiKV configuration file supports more options than command-line parameters. You can find the default configuration file in [etc/config-template.toml](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) and rename it to `config.toml`. +The TiKV configuration file supports more options than command-line parameters. You can find the default configuration file in [etc/config-template.toml](https://github.com/tikv/tikv/blob/release-4.0/etc/config-template.toml) and rename it to `config.toml`. This document only describes the parameters that are not included in command-line parameters. For more details, see [command-line parameter](/command-line-flags-for-tikv-configuration.md). diff --git a/tispark-deployment-topology.md b/tispark-deployment-topology.md index 53da7b9dc48dc..17cedb85b312a 100644 --- a/tispark-deployment-topology.md +++ b/tispark-deployment-topology.md @@ -27,8 +27,8 @@ For more information about the TiSpark architecture and how to use it, see [TiSp ## Topology templates -- [Simple TiSpark topology template](https://github.com/pingcap/docs/blob/master/config-templates/simple-tispark.yaml) -- [Complex TiSpark topology template](https://github.com/pingcap/docs/blob/master/config-templates/complex-tispark.yaml) +- [Simple TiSpark topology template](https://github.com/pingcap/docs/blob/release-4.0/config-templates/simple-tispark.yaml) +- [Complex TiSpark topology template](https://github.com/pingcap/docs/blob/release-4.0/config-templates/complex-tispark.yaml) For detailed descriptions of the configuration items in the above TiDB cluster topology file, see [Topology Configuration File for Deploying TiDB Using TiUP](/tiup/tiup-cluster-topology-reference.md). diff --git a/tiup/tiup-faq.md b/tiup/tiup-faq.md index 7d5a03c1a4dc1..72799e04b5e70 100644 --- a/tiup/tiup-faq.md +++ b/tiup/tiup-faq.md @@ -25,7 +25,7 @@ The TiUP playground component is mainly used to build a stand-alone development ## How do I write the topology file for the TiUP cluster component? -Refer to [these templates](https://github.com/pingcap/tiup/tree/master/examples) to write the topology file. The templates include: +Refer to [these templates](https://github.com/pingcap/tiup/tree/master/embed/templates/examples) to write the topology file. The templates include: - Multi-DC deployment topology - Minimal deployment topology diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 9cf28b384d0c5..b470481578f86 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -78,7 +78,7 @@ This command starts Prometheus on port 9090 to display the time series data in t ### Override PD's default configuration -First, you need to copy the [PD configuration template](https://github.com/pingcap/pd/blob/master/conf/config.toml). Assume you place the copied file to `~/config/pd.toml` and make some changes according to your need, then you can execute the following command to override PD's default configuration: +First, you need to copy the [PD configuration template](https://github.com/tikv/pd/blob/release-4.0/conf/config.toml). Assume you place the copied file to `~/config/pd.toml` and make some changes according to your need, then you can execute the following command to override PD's default configuration: {{< copyable "shell-regular" >}} diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index a9a57b21be9ed..2c3e82784d3ab 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -204,8 +204,8 @@ Solutions: * If the above error occurs frequently, it is recommended to adjust the application logic. #### TTL manager has timed out - -The transaction execution time can not exceed the GC time limit. In addition, the TTL time of pessimistic transactions has an upper limit, whose default value is 10 minutes. Therefore, a pessimistic transaction executed for more than 10 minutes will fail to commit. This timeout threshold is controlled by the TiDB parameter [performance.max-txn-ttl](https://github.com/pingcap/tidb/blob/master/config/config.toml.example). + +The transaction execution time can not exceed the GC time limit. In addition, the TTL time of pessimistic transactions has an upper limit, whose default value is 10 minutes. Therefore, a pessimistic transaction executed for more than 10 minutes will fail to commit. This timeout threshold is controlled by the TiDB parameter [performance.max-txn-ttl](https://github.com/pingcap/tidb/blob/release-4.0/config/config.toml.example). When the execution time of a pessimistic transaction exceeds the TTL time, the following error message occurs in the TiDB log: @@ -215,7 +215,7 @@ TTL manager has timed out, pessimistic locks may expire, please commit or rollba Solutions: -* First, confirm whether the application logic can be optimized. For example, large transactions may trigger TiDB's transaction size limit, which can be split into multiple small transactions. +* First, confirm whether the application logic can be optimized. For example, large transactions may trigger TiDB's transaction size limit, which can be split into multiple small transactions. * Also, you can adjust the related parameters properly to meet the application transaction logic. #### Deadlock found when trying to get lock