From cff443afda71e9457baf6c2333753bcabc4c2333 Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 10:59:32 +0800 Subject: [PATCH 1/3] add anchor check to 3.0 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 7fc2bf94a29f3..55f5f3bafea5c 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 d78780bd4c4f3df2798e1fb8c057a78248cd68e4 Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 12:39:06 +0800 Subject: [PATCH 2/3] fix 10 anchors --- certificate-authentication.md | 4 ++-- 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 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/certificate-authentication.md b/certificate-authentication.md index 4640708443bb2..2604e62af6cee 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: @@ -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 b14fbc8410ddd..bbcf2e9eb5787 100644 --- a/glossary.md +++ b/glossary.md @@ -13,7 +13,7 @@ aliases: ['/docs/v3.0/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 00fa8033559fb..d279194d7e81e 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 f7ec99387456b..eb9b62663690d 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 8068a505f0660..6de21921a18b8 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 2a73e950bab78..923bfe26cc4ac 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/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. diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 2b3dcd914308d..e791db26c6409 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 f04591c7c12f7..1f7924b97f2d8 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? From 9f5a884102be5618388dfc4c5624aafd86157c15 Mon Sep 17 00:00:00 2001 From: yikeke Date: Fri, 3 Jul 2020 12:45:57 +0800 Subject: [PATCH 3/3] fix an anchor --- tune-operating-system.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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)