From f70bd7e77bdf2bb5027e706e5847467f836fe57f Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 10:54:47 +0800 Subject: [PATCH 1/5] add anchor check to 3.1 branch --- .circleci/config.yml | 17 +++++++++++++++-- scripts/verify-link-anchors.sh | 14 ++++++++++++++ scripts/verify-links.sh | 7 +++---- 3 files changed, 32 insertions(+), 6 deletions(-) create mode 100755 scripts/verify-link-anchors.sh diff --git a/.circleci/config.yml b/.circleci/config.yml index 105c2116fb281..f61c17073355c 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -3,15 +3,23 @@ version: 2 jobs: lint: docker: - - image: circleci/ruby:2.4.1-node + - image: circleci/node:lts working_directory: ~/pingcap/docs steps: - checkout + - run: + name: Setup + command: | + mkdir ~/.npm-global + npm config set prefix '~/.npm-global' + echo 'export PATH=~/.npm-global/bin:$PATH' >> $BASH_ENV + echo 'export NODE_PATH=~/.npm-global/lib/node_modules:$NODE_PATH' >> $BASH_ENV + - run: name: "Install markdownlint" command: | - sudo npm install -g markdownlint-cli@0.17.0 + npm install -g markdownlint-cli@0.17.0 - run: name: "Lint README" @@ -29,6 +37,11 @@ jobs: command: | scripts/verify-links.sh + - run: + name: "Check link anchors" + command: | + scripts/verify-link-anchors.sh + build: docker: - image: andelf/doc-build:0.1.9 diff --git a/scripts/verify-link-anchors.sh b/scripts/verify-link-anchors.sh new file mode 100755 index 0000000000000..445159d537f15 --- /dev/null +++ b/scripts/verify-link-anchors.sh @@ -0,0 +1,14 @@ +#!/bin/bash +# +# In addition to verify-links.sh, this script additionally check anchors. +# +# See https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally if you meet permission problems when executing npm install. + +ROOT=$(unset CDPATH && cd $(dirname "${BASH_SOURCE[0]}")/.. && pwd) +cd $ROOT + +npm install -g remark-cli remark-lint breeswish/remark-lint-pingcap-docs-anchor + +echo "info: checking links anchors under $ROOT directory..." + +remark --ignore-path .gitignore -u lint -u remark-lint-pingcap-docs-anchor . --frail --quiet diff --git a/scripts/verify-links.sh b/scripts/verify-links.sh index 300b75d8401c7..70b5b38c8aba6 100755 --- a/scripts/verify-links.sh +++ b/scripts/verify-links.sh @@ -10,13 +10,12 @@ # - When a file was moved, all other references are required to be updated for now, even if alias are given # - This is recommended because of less redirects and better anchors support. # +# See https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally if you meet permission problems when executing npm install. ROOT=$(unset CDPATH && cd $(dirname "${BASH_SOURCE[0]}")/.. && pwd) cd $ROOT -if ! which markdown-link-check &>/dev/null; then - sudo npm install -g markdown-link-check@3.7.3 -fi +npm install -g markdown-link-check@3.8.1 VERBOSE=${VERBOSE:-} CONFIG_TMP=$(mktemp) @@ -50,7 +49,7 @@ fi while read -r tasks; do for task in $tasks; do ( - output=$(markdown-link-check --color --config "$CONFIG_TMP" "$task" -q) + output=$(markdown-link-check --config "$CONFIG_TMP" "$task" -q) if [ $? -ne 0 ]; then printf "$output" >> $ERROR_REPORT fi From c5fb9484e8669a8e31e56eafc8eea7d99db3b810 Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 12:24:49 +0800 Subject: [PATCH 2/5] fix 11 anchors --- certificate-authentication.md | 2 +- glossary.md | 2 +- optimistic-transaction.md | 2 +- pessimistic-transaction.md | 2 +- sql-statements/sql-statement-recover-table.md | 2 +- tidb-binlog/handle-tidb-binlog-errors.md | 2 +- tidb-lightning/deploy-tidb-lightning.md | 2 +- tidb-lightning/tidb-lightning-faq.md | 2 +- tiflash/maintain-tiflash.md | 4 ++-- tune-operating-system.md | 2 +- 10 files changed, 11 insertions(+), 11 deletions(-) diff --git a/certificate-authentication.md b/certificate-authentication.md index 643a096679915..6ac9fc5d62900 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -483,4 +483,4 @@ Also replace the old CA certificate with the combined certificate so that the cl sudo openssl x509 -req -in server-req.new.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.new.pem ``` -3. Configure the TiDB server to use the new server key and certificate. See [Configure TiDB server](#configure-tidb-server) for details. +3. Configure the TiDB server to use the new server key and certificate. See [Configure TiDB server](#configure-tidb-and-the-client-to-use-certificates) for details. diff --git a/glossary.md b/glossary.md index 60befac7377ec..9c31f873bdbfc 100644 --- a/glossary.md +++ b/glossary.md @@ -13,7 +13,7 @@ aliases: ['/docs/v3.1/glossary/'] ACID refers to the four key properties of a transaction: atomicity, consistency, isolation, and durability. Each of these properties is described below. -- **Atomicity** means that either all the changes of an operation are performed, or none of them are. TiDB ensures the atomicity of the [Region](#region) that stores the Primary Key to achieve the atomicity of transactions. +- **Atomicity** means that either all the changes of an operation are performed, or none of them are. TiDB ensures the atomicity of the [Region](#regionpeerraft-group) that stores the Primary Key to achieve the atomicity of transactions. - **Consistency** means that transactions always bring the database from one consistent state to another. In TiDB, data consistency is ensured before writing data to the memory. diff --git a/optimistic-transaction.md b/optimistic-transaction.md index bab8d0aeb03bd..33e7f968c85fe 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -63,7 +63,7 @@ However, TiDB transactions also have the following disadvantages: * In need of a centralized version manager * OOM (out of memory) when extensive data is written in the memory -To avoid potential problems in application, refer to [transaction sizes](/transaction-overview.md#transaction-size) to see more details. +To avoid potential problems in application, refer to [transaction sizes](/transaction-overview.md#transaction-sizes) to see more details. ## Transaction retries diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index 4436509bdc168..636d852854648 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -33,7 +33,7 @@ To disable the pessimistic transaction mode, modify the configuration file and a ## Behaviors -Pessimistic transactions in TiDB behave similarly to those in MySQL. See the minor differences in [Difference with MySQL InnoDB](#difference-with-mysql-innoDB). +Pessimistic transactions in TiDB behave similarly to those in MySQL. See the minor differences in [Difference with MySQL InnoDB](#difference-with-mysql-innodb). - When you perform the `SELECT FOR UPDATE` statement, transactions read the last committed data and apply a pessimistic lock on the data being read. diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index 62e60d66e65f2..3581fc6cfb9ec 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -45,7 +45,7 @@ When you use `RECOVER TABLE` in the upstream TiDB during TiDB Binlog replication + Latency occurs during replication between upstream and downstream databases. An error instance: `snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`. -For the above three situations, you can resume data replication from TiDB Binlog with a [full import of the deleted table](/ecosystem-tool-user-guide.md#full-backup-and-restore-of-tidb-cluster-data-1). +For the above three situations, you can resume data replication from TiDB Binlog with a [full import of the deleted table](/ecosystem-tool-user-guide.md#backup-and-restore). ## Examples diff --git a/tidb-binlog/handle-tidb-binlog-errors.md b/tidb-binlog/handle-tidb-binlog-errors.md index 6838b51a2c351..034d2f10b8c3d 100644 --- a/tidb-binlog/handle-tidb-binlog-errors.md +++ b/tidb-binlog/handle-tidb-binlog-errors.md @@ -33,4 +33,4 @@ Solution: Clean up the disk space and then restart Pump. Cause: When Pump is started, it notifies all Drainer nodes that are in the `online` state. If it fails to notify Drainer, this error log is printed. -Solution: Use the [binlogctl tool](/tidb-binlog/maintain-tidb-binlog-cluster.md#binlog-guide) to check whether each Drainer node is normal or not. This is to ensure that all Drainer nodes that are in the `online` state are working normally. If the state of a Drainer node is not consistent with its actual working status, use the binlogctl tool to change its state and then restart Pump. +Solution: Use the [binlogctl tool](/tidb-binlog/binlog-control.md) to check whether each Drainer node is normal or not. This is to ensure that all Drainer nodes that are in the `online` state are working normally. If the state of a Drainer node is not consistent with its actual working status, use the binlogctl tool to change its state and then restart Pump. diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 24338a9c20b62..0842db5b6b79f 100644 --- a/tidb-lightning/deploy-tidb-lightning.md +++ b/tidb-lightning/deploy-tidb-lightning.md @@ -97,7 +97,7 @@ If the data source consists of CSV files, see [CSV support](/tidb-lightning/migr This section describes two deployment methods of TiDB Lightning: -- [Deploy TiDB Lightning using TiDB Ansible](#deploy-tidb-lightning-using-ansible) +- [Deploy TiDB Lightning using TiDB Ansible](#deploy-tidb-lightning-using-tidb-ansible) - [Deploy TiDB Lightning manually](#deploy-tidb-lightning-manually) ### Deploy TiDB Lightning using TiDB Ansible diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index 18fad5c1e26e7..2ea6dd48754a6 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -61,7 +61,7 @@ If `tikv-importer` needs to be restarted: 4. Start `tikv-importer`. 5. Start `tidb-lightning` *and wait until the program fails with CHECKSUM error, if any*. * Restarting `tikv-importer` would destroy all engine files still being written, but `tidb-lightning` did not know about it. As of v3.0 the simplest way is to let `tidb-lightning` go on and retry. -6. [Destroy the failed tables and checkpoints](/troubleshoot-tidb-lightning.md#checkpoint-for-has-invalid-status) +6. [Destroy the failed tables and checkpoints](/troubleshoot-tidb-lightning.md#checkpoint-for--has-invalid-status-error-code) 7. Start `tidb-lightning` again. ## How to ensure the integrity of the imported data? diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index 46d83167c1856..b87ccffb7edaa 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -33,7 +33,7 @@ There are two ways to check the TiFlash version: ## Take a TiFlash node down -Taking a TiFlash node down differs from [Scaling in a TiFlash node](/tiflash/scale-tiflash.md#scale-in-a-tiflash-node) in that the former doesn't remove the node in TiDB Ansible; instead, it just safely shuts down the TiFlash process. +Taking a TiFlash node down differs from [Scaling in a TiFlash node](/tiflash/maintain-tiflash.md#take-a-tiflash-node-down) in that the former doesn't remove the node in TiDB Ansible; instead, it just safely shuts down the TiFlash process. Follow the steps below to take a TiFlash node down: @@ -162,7 +162,7 @@ In this case, you can balance the load pressure by adding more TiFlash nodes. Take the following steps to handle the data file corruption: -1. Refer to [Take a TiFlash node down](#take-a-tiflash-node-down) to take the corresponding TiFlash node down. +1. Refer to [Take a TiFlash node down](/tiflash/maintain-tiflash.md#take-a-tiflash-node-down) to take the corresponding TiFlash node down. 2. Delete the related data of the TiFlash node. 3. Redeploy the TiFlash node in the cluster. diff --git a/tune-operating-system.md b/tune-operating-system.md index ba4a24e6ce497..e6e6c2383b065 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -61,7 +61,7 @@ cpufreq is a module that dynamically adjusts the CPU frequency. It supports five ### NUMA CPU binding -To avoid accessing memory across Non-Uniform Memory Access (NUMA) nodes as much as possible, you can bind a thread/process to certain CPU cores by setting the CPU affinity of the thread. For ordinary programs, you can use the `numactl` command for the CPU binding. For detailed usage, see the Linux manual pages. For network interface card (NIC) interrupts, see [tune network](#tune-network). +To avoid accessing memory across Non-Uniform Memory Access (NUMA) nodes as much as possible, you can bind a thread/process to certain CPU cores by setting the CPU affinity of the thread. For ordinary programs, you can use the `numactl` command for the CPU binding. For detailed usage, see the Linux manual pages. For network interface card (NIC) interrupts, see [tune network](#network-tuning). ### Memory—transparent huge page (THP) From 2e8dab2f96cdc6b75bc8cc2d4fe2f7685392ffa1 Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 12:42:55 +0800 Subject: [PATCH 3/5] fix an anchor --- tidb-binlog/handle-tidb-binlog-errors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-binlog/handle-tidb-binlog-errors.md b/tidb-binlog/handle-tidb-binlog-errors.md index 034d2f10b8c3d..31718b2a775f7 100644 --- a/tidb-binlog/handle-tidb-binlog-errors.md +++ b/tidb-binlog/handle-tidb-binlog-errors.md @@ -33,4 +33,4 @@ Solution: Clean up the disk space and then restart Pump. Cause: When Pump is started, it notifies all Drainer nodes that are in the `online` state. If it fails to notify Drainer, this error log is printed. -Solution: Use the [binlogctl tool](/tidb-binlog/binlog-control.md) to check whether each Drainer node is normal or not. This is to ensure that all Drainer nodes that are in the `online` state are working normally. If the state of a Drainer node is not consistent with its actual working status, use the binlogctl tool to change its state and then restart Pump. +Solution: Use the [binlogctl tool](/tidb-binlog/maintain-tidb-binlog-cluster.md#binlogctl-guide) to check whether each Drainer node is normal or not. This is to ensure that all Drainer nodes that are in the `online` state are working normally. If the state of a Drainer node is not consistent with its actual working status, use the binlogctl tool to change its state and then restart Pump. From 1f6b6aaf22f860914ea7584c84dffd41a8088173 Mon Sep 17 00:00:00 2001 From: Keke Yi <40977455+yikeke@users.noreply.github.com> Date: Fri, 3 Jul 2020 12:44:37 +0800 Subject: [PATCH 4/5] Apply suggestions from code review --- tiflash/maintain-tiflash.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index b87ccffb7edaa..46d83167c1856 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -33,7 +33,7 @@ There are two ways to check the TiFlash version: ## Take a TiFlash node down -Taking a TiFlash node down differs from [Scaling in a TiFlash node](/tiflash/maintain-tiflash.md#take-a-tiflash-node-down) in that the former doesn't remove the node in TiDB Ansible; instead, it just safely shuts down the TiFlash process. +Taking a TiFlash node down differs from [Scaling in a TiFlash node](/tiflash/scale-tiflash.md#scale-in-a-tiflash-node) in that the former doesn't remove the node in TiDB Ansible; instead, it just safely shuts down the TiFlash process. Follow the steps below to take a TiFlash node down: @@ -162,7 +162,7 @@ In this case, you can balance the load pressure by adding more TiFlash nodes. Take the following steps to handle the data file corruption: -1. Refer to [Take a TiFlash node down](/tiflash/maintain-tiflash.md#take-a-tiflash-node-down) to take the corresponding TiFlash node down. +1. Refer to [Take a TiFlash node down](#take-a-tiflash-node-down) to take the corresponding TiFlash node down. 2. Delete the related data of the TiFlash node. 3. Redeploy the TiFlash node in the cluster. From 7d37dac7d27e32fb4128a5fe427711e3a7e6ccfb Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 13:03:13 +0800 Subject: [PATCH 5/5] fix 2 anchors --- auto-random.md | 2 +- certificate-authentication.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/auto-random.md b/auto-random.md index 1e07da8f6007a..c8bbe3209418e 100644 --- a/auto-random.md +++ b/auto-random.md @@ -11,7 +11,7 @@ aliases: ['/docs/v3.1/auto-random/','/docs/v3.1/reference/sql/attributes/auto-ra > > `AUTO_RANDOM` is still an experimental feature. It is **NOT** recommended that you use this attribute in the production environment. In later TiDB versions, the syntax or semantics of `AUTO_RANDOM` might change. -Before using the `AUTO_RANDOM` attribute, set `allow-auto-random = true` in the `experimental` section of the TiDB configuration file. Refer to [`allow-auto-random`](/tidb-configuration-file.md#allow-auto-random) for details. +Before using the `AUTO_RANDOM` attribute, set `allow-auto-random = true` in the `experimental` section of the TiDB configuration file. Refer to [`allow-auto-random`](/tidb-configuration-file.md#allow-auto-random-new-in-v310) for details. ## User scenario diff --git a/certificate-authentication.md b/certificate-authentication.md index 6ac9fc5d62900..a5fcf855492b5 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -267,7 +267,7 @@ First, connect TiDB using the client to configure the login verification. Then, The user certificate information can be specified by `require subject`, `require issuer`, and `require cipher`, which are used to check the X509 certificate attributes. -+ `require subject`: Specifies the `subject` information of the client certificate when you log in. With this option specified, you do not need to configure `require ssl` or x509. The information to be specified is consistent with the entered `subject` information in [Generate client keys and certificates](#generate-client-keys-and-certificates). ++ `require subject`: Specifies the `subject` information of the client certificate when you log in. With this option specified, you do not need to configure `require ssl` or x509. The information to be specified is consistent with the entered `subject` information in [Generate client keys and certificates](#generate-client-key-and-certificate). To get this option, execute the following command: