From 229d0068c61e943608ab9b923cfaaf966f293f78 Mon Sep 17 00:00:00 2001 From: Ran Date: Thu, 11 Jun 2020 11:49:08 +0800 Subject: [PATCH 1/5] *: change blacklist to blocklist --- .../expressions-pushed-down.md | 26 +++++++++---------- releases/release-3.0-ga.md | 2 +- releases/release-3.0.0-rc.3.md | 2 +- releases/release-3.0.4.md | 2 +- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/functions-and-operators/expressions-pushed-down.md b/functions-and-operators/expressions-pushed-down.md index e348efc30485d..ebe7f177c63da 100644 --- a/functions-and-operators/expressions-pushed-down.md +++ b/functions-and-operators/expressions-pushed-down.md @@ -7,7 +7,7 @@ aliases: ['/docs/dev/reference/sql/functions-and-operators/expressions-pushed-do # List of Expressions for Pushdown -When TiDB reads data from TiKV, TiDB tries to push down some expressions (including calculations of functions or operators) to be processed to TiKV. This reduces the amount of transferred data and offloads processing from a single TiDB node. This document introduces the expressions that TiDB already supports pushing down and how to prohibit specific expressions from being pushed down using blacklist. +When TiDB reads data from TiKV, TiDB tries to push down some expressions (including calculations of functions or operators) to be processed to TiKV. This reduces the amount of transferred data and offloads processing from a single TiDB node. This document introduces the expressions that TiDB already supports pushing down and how to prohibit specific expressions from being pushed down using blocklist. ## Supported expressions for pushdown @@ -20,9 +20,9 @@ When TiDB reads data from TiKV, TiDB tries to push down some expressions (includ | [JSON functions](/functions-and-operators/json-functions.md) | [JSON_TYPE(json_val)][json_type],
[JSON_EXTRACT(json_doc, path[, path] ...)][json_extract],
[JSON_UNQUOTE(json_val)][json_unquote],
[JSON_OBJECT(key, val[, key, val] ...)][json_object],
[JSON_ARRAY([val[, val] ...])][json_array],
[JSON_MERGE(json_doc, json_doc[, json_doc] ...)][json_merge],
[JSON_SET(json_doc, path, val[, path, val] ...)][json_set],
[JSON_INSERT(json_doc, path, val[, path, val] ...)][json_insert],
[JSON_REPLACE(json_doc, path, val[, path, val] ...)][json_replace],
[JSON_REMOVE(json_doc, path[, path] ...)][json_remove] | | [Date and time functions](/functions-and-operators/date-and-time-functions.md) | [`DATE_FORMAT()`](https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_date-format) | -## Blacklist specific expressions +## Blocklist specific expressions -If unexpected behavior occurs during the calculation of a function caused by its pushdown, you can quickly restore the application by blacklisting that function. Specifically, you can prohibit an expression from being pushed down by adding the corresponding functions or operator to the blacklist `mysql.expr_pushdown_blacklist`. +If unexpected behavior occurs during the calculation of a function caused by its pushdown, you can quickly restore the application by blocklisting that function. Specifically, you can prohibit an expression from being pushed down by adding the corresponding functions or operator to the blocklist `mysql.expr_pushdown_blacklist`. The schema of `mysql.expr_pushdown_blacklist` is as follows: @@ -42,29 +42,29 @@ Field description: + `name`: the name of the function that is prohibited from being pushed down. + `store_type`: specifies to which storage engine the function is prohibited from being pushed down. Currently, TiDB supports the three storage engines: `tikv`, `tidb`, and `tiflash`. `store_type` is case-insensitive. If a function is prohibited from being pushed down to multiple storage engines, use a comma to separate each engine. -+ `reason` : The reason why the function is blacklisted. ++ `reason` : The reason why the function is blocklisted. -### Add to the blacklist +### Add to the blocklist -To add one or more functions or operators to the blacklist, perform the following steps: +To add one or more functions or operators to the blocklist, perform the following steps: 1. Insert the function or operator name and the collection of storage types to be prohibited from the function pushdown to `mysql.expr_pushdown_blacklist`. 2. Execute the `admin reload expr_pushdown_blacklist;` command. -### Remove from the blacklist +### Remove from the blocklist -To remove one or more functions or operators from the blacklist, perform the following steps: +To remove one or more functions or operators from the blocklist, perform the following steps: 1. Delete the function or operator name in `mysql.expr_pushdown_blacklist`. 2. Execute the `admin reload expr_pushdown_blacklist;` command. -### Blacklist usage examples +### Blocklist usage examples -The following example demonstrates how to add the `<` and `>` operators to the blacklist, then remove `>` from the blacklist. +The following example demonstrates how to add the `<` and `>` operators to the blocklist, then remove `>` from the blocklist. -You can see whether the blacklist takes effect by checking the results returned by `EXPLAIN` statement (See [Understanding `EXPLAIN` results](/query-execution-plan.md)). +You can see whether the blocklist takes effect by checking the results returned by `EXPLAIN` statement (See [Understanding `EXPLAIN` results](/query-execution-plan.md)). ```sql tidb> create table t(a int); @@ -118,8 +118,8 @@ tidb> explain select * from t where a < 2 and a > 2; > **Note:** > > - `admin reload expr_pushdown_blacklist` only takes effect on the TiDB server that executes this SQL statement. To make it apply to all TiDB servers, execute the SQL statement on each TiDB server. -> - The feature of blacklisting specific expressions is supported in TiDB 3.0.0 or later versions. -> - TiDB 3.0.3 or earlier versions does not support adding some of the operators (such as ">", "+", "is null") to the blacklist by using their original names. You need to use their aliases (case-sensitive) instead, as shown in the following table: +> - The feature of blocklisting specific expressions is supported in TiDB 3.0.0 or later versions. +> - TiDB 3.0.3 or earlier versions does not support adding some of the operators (such as ">", "+", "is null") to the blocklist by using their original names. You need to use their aliases (case-sensitive) instead, as shown in the following table: | Operator Name | Aliases | | :-------- | :---------- | diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index b4e749ae25bf0..95d80f8d19bbe 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -63,7 +63,7 @@ On June 28, 2019, TiDB 3.0 GA is released. The corresponding TiDB Ansible versio - Improve the performance of `admin show ddl jobs` by supporting scanning data in reverse order - Add the `split table region` statement to manually split the table Region to alleviate hotspot issues - Add the `split index region` statement to manually split the index Region to alleviate hotspot issues - - Add a blacklist to prohibit pushing down expressions to Coprocessor + - Add a blocklist to prohibit pushing down expressions to Coprocessor - Optimize the `Expensive Query` log to print the SQL query in the log when it exceeds the configured limit of execution time or memory + DDL - Support migrating from character set `utf8` to `utf8mb4` diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index fa4893c9547a0..c1bec911e1ca6 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -37,7 +37,7 @@ On June 21, 2019, TiDB 3.0.0-rc.3 is released. The corresponding TiDB Ansible ve - Add the `split table region` statement to manually split the table Region to alleviate the hotspot issue [#10765](https://github.com/pingcap/tidb/pull/10765) - Add the `split index region` statement to manually split the index Region to alleviate the hotspot issue [#10764](https://github.com/pingcap/tidb/pull/10764) - Fix the incorrect execution issue when you execute multiple statements such as `create user`, `grant`, or `revoke` consecutively [#10737](https://github.com/pingcap/tidb/pull/10737) - - Add a blacklist to prohibit pushing down expressions to Coprocessor [#10791](https://github.com/pingcap/tidb/pull/10791) + - Add a blocklist to prohibit pushing down expressions to Coprocessor [#10791](https://github.com/pingcap/tidb/pull/10791) - Add the feature of printing the `expensive query` log when a query exceeds the memory configuration limit [#10849](https://github.com/pingcap/tidb/pull/10849) - Add the `bind-info-lease` configuration item to control the update time of the modified binding execution plan [#10727](https://github.com/pingcap/tidb/pull/10727) - Fix the OOM issue in high concurrent scenarios caused by the failure to quickly release Coprocessor resources, resulted from the `execdetails.ExecDetails` pointer [#10832](https://github.com/pingcap/tidb/pull/10832) diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index 99062875649c1..c2478abf3aa87 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -64,7 +64,7 @@ TiDB Ansible version: 3.0.4 - Support using aliases for tables in the point queries (for example, `select * from t tmp where a = "aa"`) [#12282](https://github.com/pingcap/tidb/pull/12282) - Fix the error occurred when not handling negative values as unsigned when inserting negative numbers into BIT type columns [#12423](https://github.com/pingcap/tidb/pull/12423) - Fix the incorrectly rounding of time (for example, `2019-09-11 11:17:47.999999666` should be rounded to `2019-09-11 11:17:48`.) [#12258](https://github.com/pingcap/tidb/pull/12258) - - Refine the usage of expression blacklist (for example, `<` is equivalent to `It`.) [#11975](https://github.com/pingcap/tidb/pull/11975) + - Refine the usage of expression blocklist (for example, `<` is equivalent to `It`.) [#11975](https://github.com/pingcap/tidb/pull/11975) - Add the database prefix to the message of non-existing function error (for example, `[expression:1305]FUNCTION test.std_samp does not exist`) [#12111](https://github.com/pingcap/tidb/pull/12111) - Server - Add the `Prev_stmt` field in slow query logs to output the previous statement when the last statement is `COMMIT` [#12180](https://github.com/pingcap/tidb/pull/12180) From 8f386483c54dcdcd7cf655fddb107166ad170c29 Mon Sep 17 00:00:00 2001 From: Ran Date: Thu, 11 Jun 2020 12:06:38 +0800 Subject: [PATCH 2/5] change black and white list to blocklist and allowlist --- online-deployment-using-ansible.md | 2 +- system-tables/system-table-inspection-result.md | 2 +- ticdc/deploy-ticdc.md | 2 +- tidb-lightning/tidb-lightning-table-filter.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/online-deployment-using-ansible.md b/online-deployment-using-ansible.md index bb694120c8a52..9112153db5f94 100644 --- a/online-deployment-using-ansible.md +++ b/online-deployment-using-ansible.md @@ -625,7 +625,7 @@ To enable the following control variables, use the capitalized `True`. To disabl | tidb_version | the version of TiDB, configured by default in TiDB Ansible branches | | process_supervision | the supervision way of processes, `systemd` by default, `supervise` optional | | timezone | the global default time zone configured when a new TiDB cluster bootstrap is initialized; you can edit it later using the global `time_zone` system variable and the session `time_zone` system variable as described in [Time Zone Support](/configure-time-zone.md); the default value is `Asia/Shanghai` and see [the list of time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) for more optional values | -| enable_firewalld | to enable the firewall, closed by default; to enable it, add the ports in [network requirements](/hardware-and-software-requirements.md#network-requirements) to the white list | +| enable_firewalld | to enable the firewall, closed by default; to enable it, add the ports in [network requirements](/hardware-and-software-requirements.md#network-requirements) to the allowlist | | enable_ntpd | to monitor the NTP service of the managed node, True by default; do not close it | | set_hostname | to edit the hostname of the managed node based on the IP, False by default | | enable_binlog | whether to deploy Pump and enable the binlog, False by default, dependent on the Kafka cluster; see the `zookeeper_addrs` variable | diff --git a/system-tables/system-table-inspection-result.md b/system-tables/system-table-inspection-result.md index 1d1e2dd089b01..c9f46c2c04720 100644 --- a/system-tables/system-table-inspection-result.md +++ b/system-tables/system-table-inspection-result.md @@ -186,7 +186,7 @@ select * from information_schema.inspection_rules where type='inspection'; In the `config` diagnosis rule, the following two diagnosis rules are executed by querying the `CLUSTER_CONFIG` system table: -* Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The white list of consistency check is as follows: +* Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The allowlist of consistency check is as follows: ```go // The whitelist of the TiDB configuration consistency check diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index 41775158d7709..d28ee7b3fbd80 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -141,7 +141,7 @@ The parameters in the above command are described as follows: - `pd`: The URL of the PD client. - `start-ts`: Specifies the starting TSO of the replication task. If this parameter is not specified or specified as `0`, the current TSO is used as the starting TSO of the replication task. - `sink-uri`: The sink address. Currently, the address can be configured to `mysql`, `tidb`, or `kafka`. For how to configure sink URI, refer to [Configure Sink URI](/ticdc/sink-url.md). -- `config`: The configuration of the replication task. Currently, this configuration supports the black & white lists and skipping specific transaction of certain `commit-ts`. +- `config`: The configuration of the replication task. Currently, this configuration supports the blocklist and allowlist and skipping specific transaction of certain `commit-ts`. After executing the above command, TiCDC starts to replicate data to the downstream MySQL (`127.0.0.1:3306`) from the specified `start-ts` (`415238226621235200`). diff --git a/tidb-lightning/tidb-lightning-table-filter.md b/tidb-lightning/tidb-lightning-table-filter.md index fbf1fffd5e92e..df41f86699a3b 100644 --- a/tidb-lightning/tidb-lightning-table-filter.md +++ b/tidb-lightning/tidb-lightning-table-filter.md @@ -1,13 +1,13 @@ --- title: TiDB Lightning Table Filter -summary: Use black and white lists to filter out tables, ignoring them during import. +summary: Use the blocklist and allowlist to filter out tables, ignoring them during import. category: reference aliases: ['/docs/dev/reference/tools/tidb-lightning/table-filter/'] --- # TiDB Lightning Table Filter -TiDB Lightning supports setting up black and white lists to ignore certain databases and tables. This can be used to skip cache tables, or manually partition the data source on a shared storage to allow multiple Lightning instances work together without interfering each other. +TiDB Lightning supports setting up the blocklist and allowlist to ignore certain databases and tables. This can be used to skip cache tables, or manually partition the data source on a shared storage to allow multiple Lightning instances work together without interfering each other. The filtering rule is similar to MySQL `replication-rules-db`/`replication-rules-table`. From a9485783e9ccd097bd92708dd937b2ea7f609b16 Mon Sep 17 00:00:00 2001 From: Ran Date: Thu, 11 Jun 2020 12:17:31 +0800 Subject: [PATCH 3/5] change whitelist to allowlist --- check-before-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/check-before-deployment.md b/check-before-deployment.md index 7cfe54ef610c5..6b6d8e2391eaf 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -130,7 +130,7 @@ sysctl -p ## Check and stop the firewall service of target machines -In TiDB clusters, the access ports between nodes must be open to ensure the transmission of information such as read and write requests and data heartbeats. In common online scenarios, the data interaction between the database and the application service and between the database nodes are all made within a secure network. Therefore, if there are no special security requirements, it is recommended to stop the firewall of the target machine. Otherwise, refer to [the port usage](/hardware-and-software-requirements.md#network-requirements) and add the needed port information to the whitelist of the firewall service. +In TiDB clusters, the access ports between nodes must be open to ensure the transmission of information such as read and write requests and data heartbeats. In common online scenarios, the data interaction between the database and the application service and between the database nodes are all made within a secure network. Therefore, if there are no special security requirements, it is recommended to stop the firewall of the target machine. Otherwise, refer to [the port usage](/hardware-and-software-requirements.md#network-requirements) and add the needed port information to the allowlist of the firewall service. The rest of this section describes how to stop the firewall service of a target machine. From 51cb62bff7b7998897ea0c3e8979864910e3d28b Mon Sep 17 00:00:00 2001 From: Ran Date: Tue, 21 Jul 2020 21:46:21 +0800 Subject: [PATCH 4/5] another batch of updates Signed-off-by: Ran --- configure-time-zone.md | 2 +- migrate-from-aurora-mysql-database.md | 12 ++++++------ sql-statements/sql-statement-admin.md | 4 ++-- sql-statements/sql-statement-flashback-table.md | 4 ++-- syncer-overview.md | 4 ++-- tidb-best-practices.md | 2 +- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/configure-time-zone.md b/configure-time-zone.md index 0c07ba25d4520..e46147e0bea8c 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -108,4 +108,4 @@ In this example, no matter how you adjust the value of the time zone, the value > **Note:** > > - Time zone is involved during the conversion of the value of Timestamp and Datetime, which is handled based on the current `time_zone` of the session. -> - For data migration, you need to pay special attention to the time zone setting of the master database and the slave database. +> - For data migration, you need to pay special attention to the time zone setting of the primary database and the secondary database. diff --git a/migrate-from-aurora-mysql-database.md b/migrate-from-aurora-mysql-database.md index e212764aa7e90..cc943b78ccbe6 100644 --- a/migrate-from-aurora-mysql-database.md +++ b/migrate-from-aurora-mysql-database.md @@ -106,20 +106,20 @@ mysql-instances: - # ID of the upstream instance or the replication group. Refer to the configuration of `source_id` in the `inventory.ini` file or configuration of `source-id` in the `dm-master.toml` file. source-id: "mysql-replica-01" - # The configuration item name of the black and white lists of the schema or table to be replicated, used to quote the global black and white lists configuration. For global configuration, see the `black-white-list` below. - black-white-list: "global" + # The configuration item name of the block and allow lists of the schema or table to be replicated, used to quote the global block and allow lists configuration. For global configuration, see the `block-allow-list` below. + block-allow-list: "global" # The configuration item name of Mydumper, used to quote the global Mydumper configuration. mydumper-config-name: "global" - source-id: "mysql-replica-02" - black-white-list: "global" + block-allow-list: "global" mydumper-config-name: "global" -# The global configuration of black and white lists. Each instance can quote it by the configuration item name. -black-white-list: +# The global configuration of block and allow lists. Each instance can quote it by the configuration item name. +block-allow-list: global: - do-tables: # The white list of the upstream table to be replicated + do-tables: # The allow list of the upstream table to be replicated - db-name: "test_db" # The database name of the table to be replicated tbl-name: "test_table" # The name of the table to be replicated diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md index ac5d07345af71..146e2f29613e1 100644 --- a/sql-statements/sql-statement-admin.md +++ b/sql-statements/sql-statement-admin.md @@ -109,7 +109,7 @@ The above statement is used to get the 64-bit checksum value of `tbl_name`. This ADMIN RELOAD expr_pushdown_blacklist; ``` -The above statement is used to reload the blacklist pushed down by the expression. +The above statement is used to reload the blocklist pushed down by the expression. {{< copyable "sql" >}} @@ -117,7 +117,7 @@ The above statement is used to reload the blacklist pushed down by the expressio ADMIN RELOAD opt_rule_blacklist; ``` -The above statement is used to reload the blacklist of logic optimization rules. +The above statement is used to reload the blocklist of logic optimization rules. ## `ADMIN PLUGINS` related statement diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index e0f01d4e550b2..7a876f72157e9 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -44,8 +44,8 @@ If a table is dropped and the GC lifetime has passed, you can no longer use the Pay attention to the following conditions and requirements when you enable TiDB Binlog and use the `FLASHBACK TABLE` statement: -* The downstream slave cluster must also support `FLASHBACK TABLE`. -* The GC lifetime of the slave cluster must be longer than that of the master cluster. +* The downstream secondary cluster must also support `FLASHBACK TABLE`. +* The GC lifetime of the secondary cluster must be longer than that of the primary cluster. * The delay of replication between the upstream and downstream might also cause the failure to recover data to the downstream. * If an error occurs when TiDB Binlog is replicating a table, you need to filter that table in TiDB Binlog and manually import all data of that table. diff --git a/syncer-overview.md b/syncer-overview.md index 37e43dd36814c..0608e1339eae1 100644 --- a/syncer-overview.md +++ b/syncer-overview.md @@ -78,7 +78,7 @@ Usage of syncer: -safe-mode to specify and enable the safe mode to make Syncer reentrant -server-id int - to specify MySQL slave sever-id (default 101) + to specify MySQL replica sever-id (default 101) -status-addr string to specify Syncer metrics (default :8271), such as `--status-addr 127:0.0.1:8271` -timezone string @@ -361,7 +361,7 @@ Before replicating data using Syncer, check the following items: > **Note:** > - > If there is a master-slave replication structure between the upstream MySQL/MariaDB servers, then choose the following version. + > If there is a source-replica replication structure between the upstream MySQL/MariaDB servers, then choose the following version. > > - 5.7.1 < MySQL version < 8.0 > - MariaDB version >= 10.1.3 diff --git a/tidb-best-practices.md b/tidb-best-practices.md index b45e25d7e20a6..30406e56b7128 100644 --- a/tidb-best-practices.md +++ b/tidb-best-practices.md @@ -30,7 +30,7 @@ This section is an introduction to these concepts. For detailed information, ref Raft is a consensus algorithm that ensures data replication with strong consistency. At the bottom layer, TiDB uses Raft to replicate data. TiDB writes data to the majority of the replicas before returning the result of success. In this way, even though a few replicas might get lost, the system still has the latest data. For example, if there are three replicas, the system does not return the result of success until data has been written to two replicas. Whenever a replica is lost, at least one of the remaining two replicas have the latest data. -To store three replicas, compared with the replication of Master-Slave, Raft is more efficient. The write latency of Raft depends on the two fastest replicas, instead of the slowest one. Therefore, the implementation of geo-distributed and multiple active data centers becomes possible by using the Raft replication. In the typical scenario of three data centers distributing in two sites, to guarantee the data consistency, TiDB just needs to successfully write data into the local data center and the closer one, instead of writing to all three data centers. However, this does not mean that cross-data center deployment can be implemented in any scenario. When the amount of data to be written is large, the bandwidth and latency between data centers become the key factors. If the write speed exceeds the bandwidth or the latency is too high, the Raft replication mechanism still cannot work well. +To store three replicas, compared with the replication of Source-Replica, Raft is more efficient. The write latency of Raft depends on the two fastest replicas, instead of the slowest one. Therefore, the implementation of geo-distributed and multiple active data centers becomes possible by using the Raft replication. In the typical scenario of three data centers distributing in two sites, to guarantee the data consistency, TiDB just needs to successfully write data into the local data center and the closer one, instead of writing to all three data centers. However, this does not mean that cross-data center deployment can be implemented in any scenario. When the amount of data to be written is large, the bandwidth and latency between data centers become the key factors. If the write speed exceeds the bandwidth or the latency is too high, the Raft replication mechanism still cannot work well. ### Distributed transactions From 31df0f3b279eb64ccca0c2d28270e8837a0842be Mon Sep 17 00:00:00 2001 From: Ran Date: Wed, 22 Jul 2020 14:42:45 +0800 Subject: [PATCH 5/5] new updates of primary-secondary --- faq/tidb-faq.md | 2 +- information-schema/information-schema-inspection-result.md | 6 +++--- sql-mode.md | 2 +- sql-statements/sql-statement-recover-table.md | 2 +- syncer-overview.md | 2 +- tidb-binlog/tidb-binlog-faq.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index 4736d78b11c98..5da9848edc9f3 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -773,7 +773,7 @@ At the beginning, many users tend to do a benchmark test or a comparison test be #### What's the relationship between the TiDB cluster capacity (QPS) and the number of nodes? How does TiDB compare to MySQL? - Within 10 nodes, the relationship between TiDB write capacity (Insert TPS) and the number of nodes is roughly 40% linear increase. Because MySQL uses single-node write, its write capacity cannot be scaled. -- In MySQL, the read capacity can be increased by adding slave, but the write capacity cannot be increased except using sharding, which has many problems. +- In MySQL, the read capacity can be increased by adding secondary, but the write capacity cannot be increased except using sharding, which has many problems. - In TiDB, both the read and write capacity can be easily increased by adding more nodes. #### The performance test of MySQL and TiDB by our DBA shows that the performance of a standalone TiDB is not as good as MySQL diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index b20f7cc16f8ab..b081943db6492 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -189,7 +189,7 @@ In the `config` diagnostic rule, the following two diagnostic rules are executed * Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The allowlist of consistency check is as follows: ```go - // The whitelist of the TiDB configuration consistency check + // The allowlist of the TiDB configuration consistency check port status.status-port host @@ -200,7 +200,7 @@ In the `config` diagnostic rule, the following two diagnostic rules are executed log.slow-query-file tmp-storage-path - // The whitelist of the PD configuration consistency check + // The allowlist of the PD configuration consistency check advertise-client-urls advertise-peer-urls client-urls @@ -211,7 +211,7 @@ In the `config` diagnostic rule, the following two diagnostic rules are executed name peer-urls - // The whitelist of the TiKV configuration consistency check + // The allowlist of the TiKV configuration consistency check server.addr server.advertise-addr server.status-addr diff --git a/sql-mode.md b/sql-mode.md index 8c18f940f4454..f372a84bd8e72 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -31,7 +31,7 @@ Ensure that you have `SUPER` privilege when setting SQL mode at `GLOBAL` level, | `IGNORE_SPACE` | If this mode is enabled, the system ignores space. For example: "user" and "user " are the same. (full support)| | `ONLY_FULL_GROUP_BY` | If a non-aggregated column that is referred to in `SELECT`, `HAVING`, or `ORDER BY` is absent in `GROUP BY`, this SQL statement is invalid, because it is abnormal for a column to be absent in `GROUP BY` but displayed by query. (full support) | | `NO_UNSIGNED_SUBTRACTION` | Does not mark the result as `UNSIGNED` if an operand has no symbol in subtraction. (full support)| -| `NO_DIR_IN_CREATE` | Ignores all `INDEX DIRECTORY` and `DATA DIRECTORY` directives when a table is created. This option is only useful for slave replication servers (syntax support only) | +| `NO_DIR_IN_CREATE` | Ignores all `INDEX DIRECTORY` and `DATA DIRECTORY` directives when a table is created. This option is only useful for secondary replication servers (syntax support only) | | `NO_KEY_OPTIONS` | When you use the `SHOW CREATE TABLE` statement, MySQL-specific syntaxes such as `ENGINE` are not exported. Consider this option when migrating across DB types using mysqldump. (syntax support only)| | `NO_FIELD_OPTIONS` | When you use the `SHOW CREATE TABLE` statement, MySQL-specific syntaxes such as `ENGINE` are not exported. Consider this option when migrating across DB types using mysqldump. (syntax support only) | | `NO_TABLE_OPTIONS` | When you use the `SHOW CREATE TABLE` statement, MySQL-specific syntaxes such as `ENGINE` are not exported. Consider this option when migrating across DB types using mysqldump. (syntax support only)| diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index ca9d625b5b9d0..7f72469df7e2e 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -50,7 +50,7 @@ RECOVER TABLE BY JOB ddl_job_id > > - Binglog version is 3.0.1 or later. > - TiDB 3.0 is used both in the upstream cluster and the downstream cluster. -> - The GC life time of the slave cluster must be longer than that of the master cluster. However, as latency occurs during data replication between upstream and downstream databases, data recovery might fail in the downstream. +> - The GC life time of the secondary cluster must be longer than that of the primary cluster. However, as latency occurs during data replication between upstream and downstream databases, data recovery might fail in the downstream. ### Troubleshoot errors during TiDB Binlog replication diff --git a/syncer-overview.md b/syncer-overview.md index 0608e1339eae1..77d6b087899a2 100644 --- a/syncer-overview.md +++ b/syncer-overview.md @@ -78,7 +78,7 @@ Usage of syncer: -safe-mode to specify and enable the safe mode to make Syncer reentrant -server-id int - to specify MySQL replica sever-id (default 101) + to specify MySQL slave sever-id (default 101) -status-addr string to specify Syncer metrics (default :8271), such as `--status-addr 127:0.0.1:8271` -timezone string diff --git a/tidb-binlog/tidb-binlog-faq.md b/tidb-binlog/tidb-binlog-faq.md index e8d1ed2746794..e82fa08ef6903 100644 --- a/tidb-binlog/tidb-binlog-faq.md +++ b/tidb-binlog/tidb-binlog-faq.md @@ -122,7 +122,7 @@ If the data in the downstream is not affected, you can redeploy Drainer on the n 2. To restore the latest data of the backup file, use Reparo to set `start-tso` = {snapshot timestamp of the full backup + 1} and `end-ts` = 0 (or you can specify a point in time). -## How to redeploy Drainer when enabling `ignore-error` in Master-Slave replication triggers a critical error? +## How to redeploy Drainer when enabling `ignore-error` in Primary-Secondary replication triggers a critical error? If a critical error is trigged when TiDB fails to write binlog after enabling `ignore-error`, TiDB stops writing binlog and binlog data loss occurs. To resume replication, perform the following steps: