fix typo "登陆" to "登录" (#913)

session1/chapter10/cert-management-data-encryption.md

@@ -1,6 +1,6 @@
 ## 10.3 证书管理与数据加密
 
-从 TiDB 3.0.8 版本开始，TiDB 支持基于证书鉴权的登录方式。采用这种方式，TiDB 通过验证不同用户提供的客户端证书来确认身份，并在登陆后使用加密连接来传输数据。相比 TiDB 用户常用的用户名密码验证方式，与 MySQL 相兼容的证书鉴权方式更安全，因此越来越多的用户使用证书鉴权来代替用户名密码验证。
+从 TiDB 3.0.8 版本开始，TiDB 支持基于证书鉴权的登录方式。采用这种方式，TiDB 通过验证不同用户提供的客户端证书来确认身份，并在登录后使用加密连接来传输数据。相比 TiDB 用户常用的用户名密码验证方式，与 MySQL 相兼容的证书鉴权方式更安全，因此越来越多的用户使用证书鉴权来代替用户名密码验证。
 
 ### 10.3.1 证书管理可以做什么
 TiDB 服务端默认采用非加密连接，因而具备监视信道流量能力的第三方可以知悉 TiDB 服务端与客户端之间发送和接受的数据，包括但不限于查询语句内容、查询结果等。若信道是不可信的，例如客户端是通过公网连接到 TiDB 服务端的，则非加密连接容易造成信息泄露，建议使用加密连接确保安全性。
@@ -14,14 +14,14 @@ TiDB 服务端默认采用非加密连接，因而具备监视信道流量能力
 TiDB 证书管理功能中使用的证书，需要符合 X.509 协议。用户先生成服务端密钥，服务端证书，客户端密钥和客户端证书，用户再通过自己的 CA(根证书) 对服务端证书和客户端证书进行签名。
 
 * 服务端验证机制：如果客户端在建立连接时，提供了 CA 证书；则会验证服务端的证书是否是由这个 CA 签发，从而验证服务端身份。
-* 客户端验证机制：如果在 TiDB 中配置了 CA 路径，则会在用户登陆时，检查客户端提供的证书是否由 CA 签发，从而验证客户端身份。
+* 客户端验证机制：如果在 TiDB 中配置了 CA 路径，则会在用户登录时，检查客户端提供的证书是否由 CA 签发，从而验证客户端身份。
 * 加密通信：在验证身份之后，会进行密钥协商，之后的数据传输将采用协商后的密钥进行加密。
 
 除了验证证书签名外，TiDB 还支持对于指定用户验证客户端证书的具体内容，包括 sbject， issuer，cipher。 这个功能的实现是通过将验证的信息写入 mysql.global_priv 系统表来完成。
 
 在用户登录时，TiDB 获取到客户端证书，会比对相应的验证内容是否符合对相关用户的要求。
 
-如果符合，则可以登陆。
+如果符合，则可以登录。
 
 ### 10.3.3 证书管理操作示例
 #### 1.制作 CA 证书
@@ -110,12 +110,12 @@ ssl-ca="path/to/ca-cert.pem"
 ```
 [INFO] [server.go:264] ["secure connection is enabled"] ["client verification enabled"=true]
 ```
-客户端在登陆 TiDB 时，指定客户端密钥和证书路径，不指定 --ssl-ca 则只会加密连接，不会验证服务端身份。
+客户端在登录 TiDB 时，指定客户端密钥和证书路径，不指定 --ssl-ca 则只会加密连接，不会验证服务端身份。
 ```
 mysql -utest -h0.0.0.0 -P4000 --ssl-cert /path/to/client-cert.pem --ssl-key /path/to/client-key.pem --ssl-ca /path/to/ca-cert.pem
 ```
 上面演示了如何制作证书和使用证书进行加密连接，接下来会演示如何使用证书验证用户身份。
-TiDB 支持在用户登陆时，验证 subject，issuer，cipher 分别是指：
+TiDB 支持在用户登录时，验证 subject，issuer，cipher 分别是指：
 
 - subject： 指定用户在连接时需要提供客户端证书的 subject 内容，对应制作客户端证书时，输入的信息。
 
@@ -193,4 +193,4 @@ sudo openssl x509 -req -in client-req.new.pem -days 365000 -CA ca-cert.pem -CAke
 使用新的证书连接 TiDB：
 ```
 mysql -utest -h0.0.0.0 -P4000 --ssl-cert /path/to/client-cert.new.pem --ssl-key /path/to/client-key.new.pem --ssl-ca /path/to/ca-cert.pem
-```
+```

session1/chapter10/privilege-management.md

@@ -66,7 +66,7 @@ CREATE TABLE `user` (
   PRIMARY KEY (`Host`,`User`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
 ```
-mysql.user 表主要记录了用户的信息和用户拥有的全局权限，Host 和 User 字段主要用于用户登陆；其中 Host 字段支持通配符功能，用户在登陆时，权限管理器首先会根据登陆指定的用户名，找到 user 表中所有包含这个用户名的行。再通过比对登陆主机的 ip 和这些行的 Host 字段，来确定登陆哪个具体用户；例如用户在 192.168.1.7 登陆 root 用户，mysql.user 表中有 `root`@`172.16.*` 和 `root`@`192.168.1.*` 这两个 User 字段为 root 的用户，那权限管理器会将登陆主机 ip 192.168.1.7 和这两个 Host 进行匹配，从而登陆  `root`@`192.168.1.*`。
+mysql.user 表主要记录了用户的信息和用户拥有的全局权限，Host 和 User 字段主要用于用户登录；其中 Host 字段支持通配符功能，用户在登录时，权限管理器首先会根据登录指定的用户名，找到 user 表中所有包含这个用户名的行。再通过比对登录主机的 ip 和这些行的 Host 字段，来确定登录哪个具体用户；例如用户在 192.168.1.7 登录 root 用户，mysql.user 表中有 `root`@`172.16.*` 和 `root`@`192.168.1.*` 这两个 User 字段为 root 的用户，那权限管理器会将登录主机 ip 192.168.1.7 和这两个 Host 进行匹配，从而登录  `root`@`192.168.1.*`。
 
 #### 2.mysql.table, mysql.db 表解析：
 
@@ -119,7 +119,7 @@ mysql.tables_priv 和 mysql.db 主要记录了将权限授予给用户的信息
 在进行类似 GRANT, REVOKE 等对用户的权限修改操作时，TiDB 会开启一个内部 sql 事务，用 INSERT, UPDATE, DELETE 修改对应的权限表，然后提交内部事务，如果提交成功，权限管理器会刷新内存中的权限表。
 
 ### 10.1.3 权限管理系统操作示例
-创建一个用户名为 developer 且能在 192.168.0.* 这一子网中登陆的用户，密码为  'test_user'
+创建一个用户名为 developer 且能在 192.168.0.* 这一子网中登录的用户，密码为  'test_user'
 
 ```
 root> CREATE USER 'developer'@'192.168.0.%' IDENTIFIED BY 'test_user';
@@ -132,11 +132,11 @@ root> GRANT INSERT, UPDATE ON app.write_table TO 'developer'@'192.168.0.%';
 查看 developer 用户当前的权限。
 ```
 root> SHOW GRANTS FOR 'developer'@'192.168.0.%';
-GRANT USAGE ON *.* TO 'developer'@'192.168.0.%'                      
+GRANT USAGE ON *.* TO 'developer'@'192.168.0.%'                     
 GRANT Select ON app.read_table TO 'developer'@'192.168.0.%'
 GRANT Insert,Update,Delete ON app.write_table TO 'developer'@'192.168.0.%'
 ```
-然后用 developer 登陆，尝试使用权限。
+然后用 developer 登录，尝试使用权限。
 ```
 developer> SEECT * FROM app.read_table;
 Empty set (0.01 sec)
@@ -160,4 +160,4 @@ root> DROP USER 'developer'@'192.168.0.%'
 ```
 
 ### 10.1.4 小结
-本节主要介绍了 TiDB 权限相关操作的使用方法；介绍了如何创建一个用户，授予一些权限。如何撤销权限和删除用户。下一节将进一步深入 TiDB 权限管理模块，讲解 RBAC 的原理和使用方法。
+本节主要介绍了 TiDB 权限相关操作的使用方法；介绍了如何创建一个用户，授予一些权限。如何撤销权限和删除用户。下一节将进一步深入 TiDB 权限管理模块，讲解 RBAC 的原理和使用方法。

session1/chapter10/rbac.md

@@ -31,7 +31,7 @@ TiDB 的基于角色的访问控制 (RBAC) 系统的实现类似于 MySQL 8.0 
 主要依赖以下系统表：
 
 - mysql.user
-复用用户表，区别是 Account_Locked 字段，角色的值是 Y，也就是不能登陆.
+复用用户表，区别是 Account_Locked 字段，角色的值是 Y，也就是不能登录.
 
 ```sql
 +------+------+----------+-------------+-------------+-------------+-------------+-------------+-----------+--------------+------------+-----------------+------------+--------------+------------+-----------------------+------------------+--------------+------------------+----------------+---------------------+--------------------+------------+------------------+------------+--------------+------------------+----------------+----------------+---------------+
@@ -86,7 +86,7 @@ GRANT SELECT ON db_1.* TO 'r_1'@'%';
 grant r_1 to test@'%';
 ```
 
-- 启用默认角色，在登陆时，默认启用的角色会被自动启用：
+- 启用默认角色，在登录时，默认启用的角色会被自动启用：
 
 ```sql
 SET DEFAULT ROLE 'r_1';
@@ -197,4 +197,4 @@ ERROR 1044 (42000): Access denied for user 'bi_user'@'%' to database 'mysql'
 ```
 
 ### 10.2.5 小结
-本小节介绍了 RBAC 的原理和使用方式，企业用户可以用 RBAC 构建出一套灵活的权限管理机制。下一节中将介绍 TiDB 的另一种身份验证方式——证书验证。
+本小节介绍了 RBAC 的原理和使用方式，企业用户可以用 RBAC 构建出一套灵活的权限管理机制。下一节中将介绍 TiDB 的另一种身份验证方式——证书验证。

session1/chapter10/tidb-security.md

@@ -1,6 +1,6 @@
 ## 第10章 TiDB 安全
 
-本章介绍了 TiDB 的三大安全机制：权限管理，RBAC 以及证书管理和传输加密。权限管理功能提供了对于用户和数据库访问权限的基本管理功能，适用于各种访问控制场景；RBAC 在权限管理功能之上构建了角色这一概念，通过角色可以方便的管理大量的用户和复杂的授权关系；证书管理和数据加密功能提供了除密码之外的用户认证登陆方式，用户通过证书认证登陆后会采用 TLS 加密与服务端的通信数据，避免中间人攻击。
+本章介绍了 TiDB 的三大安全机制：权限管理，RBAC 以及证书管理和传输加密。权限管理功能提供了对于用户和数据库访问权限的基本管理功能，适用于各种访问控制场景；RBAC 在权限管理功能之上构建了角色这一概念，通过角色可以方便的管理大量的用户和复杂的授权关系；证书管理和数据加密功能提供了除密码之外的用户认证登录方式，用户通过证书认证登录后会采用 TLS 加密与服务端的通信数据，避免中间人攻击。
 
 ## 目录
 

session2/chapter1/tidb-operator-deployment-public-eks.md

@@ -201,7 +201,7 @@ default_cluster_tidb_count = 4
 
 ### 自定义 AWS 相关的资源
 
-由于 TiDB 服务通过 [Internal Elastic Load Balancer](https://aws.amazon.com/blogs/aws/internal-elastic-load-balancers/) 暴露，默认情况下，会创建一个 Amazon EC2 实例作为堡垒机，访问创建的 TiDB 集群。堡垒机上预装了 MySQL 和 Sysbench，所以可以通过 SSH 方式登陆到堡垒机后通过 ELB 访问 TiDB。如果的 VPC 中已经有了类似的 EC2 实例，可以通过设置 `create_bastion` 为 `false` 禁掉堡垒机的创建。
+由于 TiDB 服务通过 [Internal Elastic Load Balancer](https://aws.amazon.com/blogs/aws/internal-elastic-load-balancers/) 暴露，默认情况下，会创建一个 Amazon EC2 实例作为堡垒机，访问创建的 TiDB 集群。堡垒机上预装了 MySQL 和 Sysbench，所以可以通过 SSH 方式登录到堡垒机后通过 ELB 访问 TiDB。如果的 VPC 中已经有了类似的 EC2 实例，可以通过设置 `create_bastion` 为 `false` 禁掉堡垒机的创建。
 
 TiDB 版本和组件数量也可以在 `terraform.tfvars` 中修改，可以按照自己的需求配置。
 
@@ -257,14 +257,14 @@ operator_values = "./operator_values.yaml"
 ```hcl
 module example-cluster {
   source = "../modules/aws/tidb-cluster"
-  
+
   # The target EKS, required
   eks = local.eks
   # The subnets of node pools of this TiDB cluster, required
   subnets = local.subnets
   # TiDB cluster name, required
   cluster_name    = "example-cluster"
-  
+
   # Helm values file
   override_values = file("example-cluster.yaml")
   # TiDB cluster version
@@ -431,7 +431,7 @@ module "tidb-cluster-b" {
   providers = {
     helm = "helm.eks"
   }
-  
+
   cluster_name = "tidb-cluster-b"
   eks          = module.tidb-operator.eks
   ssh_key_name = module.key-pair.key_name

session2/chapter1/tidb-operator-deployment-public-jdcloud.md

@@ -140,9 +140,9 @@ TiDB 分布式数据库默认会使用很多文件描述符，工作节点和上
 
 - 重置京东云 Kubernetes 集群所有 Node 的登录密码
 
-   ![重置登陆密码](/res/session2/chapter1/tidb-operator-deployment-public-jdcloud/1.png)
+   ![重置登录密码](/res/session2/chapter1/tidb-operator-deployment-public-jdcloud/1.png)
 
-- 控制台登陆 Node
+- 控制台登录 Node
 
 - 设置工作节点的 `ulimit` 值，详情可以参考[如何设置 ulimit](https://access.redhat.com/solutions/61334)
 

session2/chapter2/br-in-action.md

@@ -90,7 +90,7 @@ UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_lif
 
 SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time';
 
-720h 
+720h
 ```
 
 2. 备份存储位置
@@ -144,7 +144,7 @@ bin/br backup full  --pd "192.168.122.101:2379" --storage "local:///data_nfs1/ba
 	* 查询 infoSchema 获取元数据。
 	* 发送备份请求：{"cluster_id":6801677637806839235,"start_key":"dIAAAAAAAAAvX3IAAAAAAAAAAA==","end_key":"dIAAAAAAAAAvX3L//////////wA=","end_version":415142848617512967,"concurrency":4,"storage_backend":{Backend":{"Local":{"path":"/data_nfs1/backup"}}}}"
 	* 各个 TiKV 节点开始执行备份，执行命令完成后，返回到 BR 进行统计。
-	* 执行表的checksum [table=`br_test`.`br_table`] [Crc64Xor=12896770389982935753] [TotalKvs=100000] [TotalBytes=4788890] 
+	* 执行表的checksum [table=`br_test`.`br_table`] [Crc64Xor=12896770389982935753] [TotalKvs=100000] [TotalBytes=4788890]
 	* 保存备份的元数据。
 	* 完成备份。
 
@@ -217,4 +217,4 @@ bin/br backup table --db "br_test"  --table "br_table"  --pd "192.168.122.101:23
 bin/br restore table --db "br_test" --table "br_table" --pd "192.168.122.101:2379" --storage "local:///data_nfs1/backup"
 ```
 
-通过上述实践，我们了解了 BR 基本用法，想要了解具体代码实现可以登陆 BR 项目主页(https://github.com/pingcap/br), 欢迎提供更多的使用建议，帮助我们改进。
+通过上述实践，我们了解了 BR 基本用法，想要了解具体代码实现可以登录 BR 项目主页(https://github.com/pingcap/br), 欢迎提供更多的使用建议，帮助我们改进。

session3/chapter6/tidb-operator-trouble-shooting.md

@@ -81,7 +81,7 @@ kubectl  get pods -n kube-system | grep core
 coredns-9d85f5447-642rs          1/1     Running   1          13h
 coredns-9d85f5447-8swr2          1/1     Running   1          13h
 # 若 CoreDNS 正常运行仍不能成功解析 DNS
-# 登陆 pd pod，检查 /etc/resov 中的 nameserver 是否配置正确
+# 登录 pd pod，检查 /etc/resov 中的 nameserver 是否配置正确
 kubectl exec -it tidb-cluster-pd-0 -n=tidb  -- cat /etc/resolv.conf
 ```