diff --git a/check-before-deployment.md b/check-before-deployment.md
index 7ea089888d49c..7a0253a476bb8 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.
 
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/functions-and-operators/expressions-pushed-down.md b/functions-and-operators/expressions-pushed-down.md
index 1700b865d1e9e..0dcb9cca857c9 100644
--- a/functions-and-operators/expressions-pushed-down.md
+++ b/functions-and-operators/expressions-pushed-down.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/functions-and-operators/expressions-pushed-down/','/docs/de
 
 # 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
 
@@ -19,9 +19,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],<br/> [JSON_EXTRACT(json_doc, path[, path] ...)][json_extract],<br/> [JSON_UNQUOTE(json_val)][json_unquote],<br/> [JSON_OBJECT(key, val[, key, val] ...)][json_object],<br/> [JSON_ARRAY([val[, val] ...])][json_array],<br/> [JSON_MERGE(json_doc, json_doc[, json_doc] ...)][json_merge],<br/> [JSON_SET(json_doc, path, val[, path, val] ...)][json_set],<br/> [JSON_INSERT(json_doc, path, val[, path, val] ...)][json_insert],<br/> [JSON_REPLACE(json_doc, path, val[, path, val] ...)][json_replace],<br/> [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:
 
@@ -41,29 +41,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);
@@ -117,8 +117,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/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md
index 86f23f3002466..b081943db6492 100644
--- a/information-schema/information-schema-inspection-result.md
+++ b/information-schema/information-schema-inspection-result.md
@@ -186,10 +186,10 @@ select * from information_schema.inspection_rules where type='inspection';
 
 In the `config` diagnostic rule, the following two diagnostic 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
+    // 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/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/online-deployment-using-ansible.md b/online-deployment-using-ansible.md
index b914222748fc6..4bfdb23dc2ecd 100644
--- a/online-deployment-using-ansible.md
+++ b/online-deployment-using-ansible.md
@@ -626,7 +626,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/releases/release-3.0-ga.md b/releases/release-3.0-ga.md
index bbcf32a2be981..3230dfff1d0db 100644
--- a/releases/release-3.0-ga.md
+++ b/releases/release-3.0-ga.md
@@ -62,7 +62,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 325ac7bcb61ab..de11cfa0f889b 100644
--- a/releases/release-3.0.0-rc.3.md
+++ b/releases/release-3.0.0-rc.3.md
@@ -36,7 +36,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 cfb490d4dfa3e..c260ae514bdaf 100644
--- a/releases/release-3.0.4.md
+++ b/releases/release-3.0.4.md
@@ -63,7 +63,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)
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-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/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 37e43dd36814c..77d6b087899a2 100644
--- a/syncer-overview.md
+++ b/syncer-overview.md
@@ -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 612e6717ce241..466a22a9a4f91 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
 
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: