数据库系列之TiDB日常操作维护
TiDB的操作维护相较其它开源数据库如MySQL要简便很多，安装升级等操作基本可以一键完成，本文简要介绍了TiDB的版本升级、扩缩容以及日常操作维护等
TiDB的操作维护相较其它开源数据库如MySQL要简便很多，安装升级等操作基本可以一键完成，本文简要介绍了TiDB的版本升级、扩缩容以及日常操作维护等。
1、TiDB版本升级
TiDB支持滚动升级，使用TiUP可以在线升级，也可以使用TiUP进行离线升级。如果是基于K8S部署的，也可以使用TiDB Operator进行升级。TiDB 4.0之前的版本则使用TiDB Ansible的方式进行升级。本部分主要介绍使用TiUP进行在线和离线升级。
1.1 使用TiUP升级
1.1.1 将集群升级到指定版本
使用如下命令在线升级：
tiup cluster upgrade <cluster-name> <version>
以升级到 v4.0.0 版本为例：
tiup cluster upgrade tidb-test v4.0.0
滚动升级会逐个升级所有的组件，升级TiKV期间，会逐个将TiKV上的所有leader切走再停止该TiKV实例。默认超时时间为 5分钟，超过后会直接停止实例。
- 如果不希望驱逐leader，而希望立刻升级，可以在命令中指定 --force，该方式会造成性能抖动，但是不会造成数据损失。
- 如果希望保持性能稳定，则需要保证TiKV上的所有leader驱逐完成后再停止该TiKV实例，可以指定–transfer-timeout为一个超大值，如 --transfer-timeout 100000000，单位为s。
1.1.2 升级后验证
执行 display 命令来查看最新的集群版本 TiDB Version：
[root@tango-01 ~]# tiup cluster display tidb-test
Starting component `cluster`: /root/.tiup/components/cluster/v1.2.3/tiup-cluster display tidb-test
Cluster type: tidb
Cluster name: tidb-test
Cluster version: v4.0.0
SSH type: builtin
1.2 使用TiUP离线升级
1.2.1 更新TiUP离线镜像
- 下载部署新版本的TiUP离线镜像
- 在执行 local_install.sh 后，TiUP会完成覆盖升级。
此时离线镜像已经更新成功。如果覆盖后发现TiUP运行报错，可能是manifest未更新导致，可尝试 rm -rf ~/.tiup/manifests 后再使用TiUP。
1.2.2 升级TiDB集群
在更新本地镜像后，可参考1.1部分内容升级TiDB集群。
2、TiDB扩缩容
TiDB集群可以在不中断线上服务的情况下进行扩容和缩容，扩缩容根据部署方式和版本不同有不同的方法，本部分介绍如何使用TiUP扩容缩容集群中的TiDB、TiKV、PD节点。
例如，集群原拓扑结构如下所示：
| 主机IP | 服务 |
|---|---|
| 192.168.112.101 | TiDB +PD+TiKV |
| 192.168.112.102 | TiDB +PD+TiKV |
| 192.168.112.103 | TiDB +PD+TiKV |
| 192.168.112.10 | Monitor |
2.1 扩容TiDB/PD/TiKV节点
如果要添加一个TiDB节点，IP 地址为192.168.112.10，可以按照如下步骤进行操作。
注意：添加PD节点和添加TiDB节点的步骤类似。添加TiKV节点前，建议预先根据集群的负载情况调整PD调度参数。
2.1.1 编写扩容拓扑配置
1）在scale-out.yaml文件添加扩容拓扑配置：
vi scale-out.yaml
tidb_servers:
- host: 192.168.112.10
ssh_port: 22
port: 4000
status_port: 10080
deploy_dir: /data/deploy/install/deploy/tidb-4000
log_dir: /data/deploy/install/log/tidb-4000
2）TiKV 配置文件参考：
tikv_servers:
- host: 192.168.112.10
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: /data/deploy/install/deploy/tikv-20160
data_dir: /data/deploy/install/data/tikv-20160
log_dir: /data/deploy/install/log/tikv-20160
3）PD 配置文件参考：
pd_servers:
- host: 192.168.112.10
ssh_port: 22
name: pd-1
client_port: 2379
peer_port: 2380
deploy_dir: /data/deploy/install/deploy/pd-2379
data_dir: /data/deploy/install/data/pd-2379
log_dir: /data/deploy/install/log/pd-2379
2.1.2 执行扩容命令
tiup cluster scale-out tidb-test scale-out.yaml
预期输出 Scaled cluster tidb-test out successfully信息，表示扩容操作成功。
2.1.3 检查集群状态
tiup cluster display tidb-test
打开浏览器访问监控平台http://192.168.112.10:3000，监控整个集群和新增节点的状态。扩容后，集群拓扑结构如下所示：
| 主机IP | 服务 |
|---|---|
| 192.168.112.101 | TiDB +PD+TiKV |
| 192.168.112.102 | TiDB +PD+TiKV |
| 192.168.112.103 | TiDB +PD+TiKV |
| 192.168.112.10 | Monitor+TiKV |
2.2 缩容TiDB/PD/TiKV节点
如果要移除IP地址为192.168.112.10的一个 TiKV节点，可以按照如下步骤进行操作。
2.2.1 查看节点ID信息
[root@tango-01 src]# tiup cluster display tidb-test
Starting component `cluster`: /root/.tiup/components/cluster/v1.2.3/tiup-cluster display tidb-test
Cluster type: tidb
Cluster name: tidb-test
Cluster version: v4.0.0
SSH type: builtin
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
192.168.112.10:9093 alertmanager 192.168.112.10 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
192.168.112.10:3000 grafana 192.168.112.10 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
192.168.112.101:2379 pd 192.168.112.101 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379
192.168.112.102:2379 pd 192.168.112.102 2379/2380 linux/x86_64 Up|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379
192.168.112.103:2379 pd 192.168.112.103 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379
192.168.112.10:9090 prometheus 192.168.112.10 9090 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
192.168.112.101:4000 tidb 192.168.112.101 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
192.168.112.102:4000 tidb 192.168.112.102 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
192.168.112.103:4000 tidb 192.168.112.103 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
192.168.112.10:20160 tikv 192.168.112.10 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
192.168.112.101:20160 tikv 192.168.112.101 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
192.168.112.102:20160 tikv 192.168.112.102 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
192.168.112.103:20160 tikv 192.168.112.103 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
Total nodes: 13
2.2.2 执行缩容操作
tiup cluster scale-in tidb-test --node 192.168.112.10:20160
其中 --node 参数为需要下线节点的 ID。预期输出Scaled cluster tidb-test out successfully信息，表示缩容操作成功。
2.2.3 检查集群状态
下线需要一定时间，下线节点的状态变为 Tombstone 就说明下线成功。
执行如下命令检查节点是否下线成功：
tiup cluster display <cluster-name>
3、TiDB数据库管理操作
3.1 TiUP常见运维操作
使用TiUP运维TiDB集群的常见操作，包括查看集群列表、启动集群、查看集群状态、修改配置参数、关闭集群、销毁集群等。
3.1.1 查看集群列表
TiUP cluster组件可以用来管理多个TiDB集群，在每个TiDB集群部署完毕后，该集群会出现在TiUP的集群列表里，可以使用 list 命令来查看。
[root@tango-01 ~]# tiup cluster list
Starting component `cluster`: /root/.tiup/components/cluster/v1.2.3/tiup-cluster list
Name User Version Path PrivateKey
---- ---- ------- ---- ----------
tidb-test tidb v4.0.0 /root/.tiup/storage/cluster/clusters/tidb-test /root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa
3.1.2 启动集群
启动集群操作会按PD -> TiKV -> Pump -> TiDB -> TiFlash -> Drainer的顺序启动整个TiDB集群所有组件（同时也会启动监控组件）：
tiup cluster start ${cluster-name}
该命令支持通过-R和-N参数来只启动部分组件。例如，下列命令只启动PD组件：
tiup cluster start ${cluster-name} -R pd
注意：若通过-R和-N启动指定组件，需要保证启动顺序正确（例如需要先启动PD才能启动TiKV），否则可能导致启动失败。
3.1.3 查看集群状态
集群启动之后需要检查每个组件的运行状态，以确保每个组件工作正常。TiUP提供了display命令，节省了登陆到每台机器上去查看进程的时间。
tiup cluster display tidb-test
3.1.4 修改配置参数
集群运行过程中，如果需要调整某个组件的参数，可以使用 edit-config 命令来编辑参数。具体的操作步骤如下：
1）以编辑模式打开该集群的配置文件：
tiup cluster edit-config ${cluster-name}
2）设置参数：
首先确定配置的生效范围，有以下两种生效范围：
- 如果配置的生效范围为该组件全局，则配置到 server_configs。例如：
server_configs:
tidb:
log.slow-threshold: 300
- 如果配置的生效范围为某个节点，则配置到具体节点的 config 中。例如：
tidb_servers:
- host: 192.168.112.10
port: 4000
config:
log.slow-threshold: 300
3）执行 reload 命令滚动分发配置、重启相应组件：
tiup cluster reload ${cluster-name} [-N <nodes>] [-R <roles>]
3.1.5 Hotfix版本替换
在某些场景下（例如Debug），可能需要用一个临时的包替换正在运行的组件，此时可以用 patch命令：
tiup cluster patch <cluster-name> <package-path> [flags]
例如，有一个TiDB实例的hotfix包放在/tmp/tidb-hotfix.tar.gz目录下。如果此时想要替换集群上的所有TiDB实例，则可以执行以下命令：
tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -R tidb
或者只替换其中一个TiDB实例：
tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -N 192.168.112.101:4000
3.1.6 重命名集群
部署并启动集群后，可以通过tiup cluster rename命令来对集群重命名：
tiup cluster rename ${cluster-name} ${new-name}
注意：
- 重命名集群会重启监控（Prometheus 和 Grafana）
- 重命名集群之后Grafana可能会残留一些旧集群名的面板，需要手动删除这些面板
3.1.7 关闭集群
关闭集群操作会按Drainer -> TiFlash -> TiDB -> Pump -> TiKV -> PD的顺序关闭整个TiDB集群所有组件（同时也会关闭监控组件）：
tiup cluster stop ${cluster-name}
和 start 命令类似，stop 命令也支持通过-R和-N参数来只停止部分组件。例如，下列命令只停止TiDB组件：
tiup cluster stop ${cluster-name} -R tidb
3.1.8 清除集群数据
此操作会关闭所有服务，并清空其数据目录或/和日志目录，并且无法恢复，需要谨慎操作。
1）清空集群所有服务的数据，但保留日志：
tiup cluster clean ${cluster-name} --data
2）清空集群所有服务的日志，但保留数据：
tiup cluster clean ${cluster-name} --log
3）清空集群所有服务的数据和日志：
tiup cluster clean ${cluster-name} --all
4）清空Prometheus以外的所有服务的日志和数据：
tiup cluster clean ${cluster-name} --all --ignore-role prometheus
5）清空节点192.168.112.101:9000 以外的所有服务的日志和数据：
tiup cluster clean ${cluster-name} --all --ignore-node 192.168.112.101:9000
6）清空部署在192.168.112.101以外的所有服务的日志和数据：
tiup cluster clean ${cluster-name} --all --ignore-node 192.168.112.101
3.1.9 销毁集群
销毁集群操作会关闭服务，清空数据目录和部署目录，并且无法恢复，需要谨慎操作。
tiup cluster destroy ${cluster-name}
3.2 权限管理
3.2.1 与MySQL安全特性差异
除以下功能外，TiDB支持与MySQL 5.7类似的安全特性。
- 仅支持 mysql_native_password 密码验证或证书验证登陆方案。
- 不支持外部身份验证方式（如 LDAP）。
- 不支持列级别权限设置。
- 不支持密码过期，最后一次密码变更记录以及密码生存期。
- 不支持权限属性max_questions，max_updated，max_connections 以及 max_user_connections。
- 不支持密码验证。
3.2.2 TiDB权限管理
1）TiDB的权限管理包括授权GRANT、收回权限Revoke、查看用户权限Show Grants等。TiDB用户目前拥有的权限可以在INFORMATION_SCHEMA.USER_PRIVILEGES表中查找到。
2）TiDB权限相关的表全部存储在这几张表内
- mysql.user：用户账户，全局权限
- mysql.db：数据库级别的权限
- mysql.tables_priv：表级别的权限
- mysql.columns_priv：列级别的权限，当前暂不支持
这几张表包含了数据的生效范围和权限信息。例如，mysql.user表的部分数据：
SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1;
+------|------|-------------|-------------+
| User | Host | Select_priv | Insert_priv |
+------|------|-------------|-------------+
| root | % | Y | Y |
+------|------|-------------|-------------+
这条记录中，Host和User决定了root用户从任意主机(%)发送过来的连接请求可以被接受，而Select_priv和Insert_priv表示用户拥有全局的Select和Insert权限。mysql.user这张表里面的生效范围是全局的。
3.2.3 TiDB用户账户管理
TidB用户账户管理包括创建用户CREATE USER、删除用户DROP USER以及修改用户密码等。
3.3 数据误操作保护
当出现数据误操作如drop table的时候，可以通过flashback的方法进行数据恢复。
1）测试表误删除恢复
mysql -uroot -P4000 -h127.0.0.1 -e "drop table sbtest.sbtest1"
mysql -uroot -P4000 -h127.0.0.1 -e "flashback table sbtest.sbtest1"
2）测试表截断操作恢复
mysql -uroot -P4000 -h127.0.0.1 -e "truncate table sbtest.sbtest1"
mysql -uroot -P4000 -h127.0.0.1 -e "flashback table sbtest.sbtest1 to sbtest.sbtest1_tmp"
3）测试数据误删、误更新恢复
mysql -uroot -P4000 -h127.0.0.1 -e "delete from sbtest.sbtest1 limit 100000"
进入 MySQL 客户端执行如下 SQL，校验数据完整：
set tidb_snapshot='2020/07/10 15:00:00';
select count(*) from sbtest.sbtest1;
3.4 开启审计日志功能
3.4.1 创建用户审计规则
1）使用root登录，创建用户userA的审计规则
drop user 'userA';
drop user 'userB';
create user 'userA'@'%' identified by '123456';
grant create user on *.* to 'userA'@'%' with grant option;
grant select,update,delete,insert,reload on test.* to 'userA'@'%' with grant option;
grant create,alter,drop on test.* to 'userA'@'%' with grant option;
flush privileges;
insert into mysql.tidb_audit_table_access (user, db, tbl, access_type) values ("userA", 'test', '.*', 'Delete,Truncate,DropTable');
2）登录userA，并在一段时间后退出，观察tidb-audit.log 日志输出信息
3.4.2 用户管理审计
1）使用userA用户登录数据库，执行创建用户操作
create user 'userB'@'%' identified by '123456';
grant select on test.* to 'userB'@'%';
2）观察tidb-audit.log日志输出信息，EVENT_CLASS=GENERAL 的事件会审计userA用户执行的创建用户及授权的操作。
3.4.3 分布式数据库操作审计
1）使用root登录，创建用户root用户的审计规则
insert into mysql.tidb_audit_table_access (user, db, tbl, access_type) values ("root", '.*', '.*','');
2）使用root用户执行DML、DDL、DCL及DQL语句。
set global connect_timeout=100;
select * from test.t1;
delete from test.t1 limit 1;
truncate table test.t1;
drop table test.t1;
create table test.t2(id int prmary key);
alter table test.t2 add c varchar(10);
create user 'userC'@'%' identified by '123456';
grant all on *.* to 'userC'@'%';
3）查看tidb-audit.log审计日志
3.5 慢查询日志
TiDB会将执行时间超过slow-threshold（默认值为 300 毫秒）的语句输出到slow-query-file（默认值：“tidb-slow.log”）日志文件中，用于帮助用户定位慢查询语句，分析和解决SQL执行的性能问题。TiDB默认启用慢查询日志，可以修改配置enable-slow-log来启用或禁用它。
3.5.1 慢日志内存映射表
用户可通过查询INFORMATION_SCHEMA.SLOW_QUERY表来查询慢查询日志中的内容，表中列名和慢日志中字段名一一对应，表结构可查看SLOW_QUERY表 中的介绍。
注意：每次查询SLOW_QUERY表时，TiDB都会去读取和解析一次当前的慢查询日志。
TiDB 4.0 中，SLOW_QUERY已经支持查询任意时间段的慢日志，即支持查询已经被rotate的慢日志文件的数据。用户查询时只需要指定TIME时间范围即可定位需要解析的慢日志文件。如果查询不指定时间范围，则仍然只解析当前的慢日志文件，示例如下：
1）不指定时间范围时，只会解析当前 TiDB 正在写入的慢日志文件的慢查询数据：
select count(*),
min(time),
max(time)
from slow_query;
+----------+----------------------------+----------------------------+
| count(*) | min(time) | max(time) |
+----------+----------------------------+----------------------------+
| 122492 | 2020-03-11 23:35:20.908574 | 2020-03-25 19:16:38.229035 |
+----------+----------------------------+----------------------------+
2）指定查询2020-03-10 00:00:00到2020-03-11 00:00:00时间范围后，会定位指定时间范围内的慢日志文件后解析慢查询数据：
select count(*),
min(time),
max(time)
from slow_query
where time > '2020-03-10 00:00:00'
and time < '2020-03-11 00:00:00';
+----------+----------------------------+----------------------------+
| count(*) | min(time) | max(time) |
+----------+----------------------------+----------------------------+
| 2618049 | 2020-03-10 00:00:00.427138 | 2020-03-10 23:00:22.716728 |
+----------+----------------------------+----------------------------+
注意：
TiDB 4.0中新增了CLUSTER_SLOW_QUERY系统表，用来查询所有 TiDB节点的慢查询信息，表结构在SLOW_QUERY的基础上多增加了INSTANCE列，表示该行慢查询信息来自的TiDB节点地址。使用方式和SLOW_QUERY系统表一样。关于查询CLUSTER_SLOW_QUERY表，TiDB会把相关的计算和判断下推到其他节点执行，而不是把其他节点的慢查询数据都取回来在一台TiDB上执行。
3.5.2 用pt-query-digest工具分析TiDB慢日志
可以用pt-query-digest工具分析TiDB慢日志。
pt-query-digest --report tidb-slow.log
输出样例：
# 320ms user time, 20ms system time, 27.00M rss, 221.32M vsz
# Current date: Mon Mar 18 13:18:51 2019
# Hostname: localhost.localdomain
# Files: tidb-slow.log
# Overall: 1.02k total, 21 unique, 0 QPS, 0x concurrency _________________
# Time range: 2019-03-18-12:22:16 to 2019-03-18-13:08:52
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 218s 10ms 13s 213ms 30ms 1s 19ms
# Query size 175.37k 9 2.01k 175.89 158.58 122.36 158.58
# Commit time 46ms 2ms 7ms 3ms 7ms 1ms 3ms
# Conn ID 71 1 16 8.88 15.25 4.06 9.83
# Process keys 581.87k 2 103.15k 596.43 400.73 3.91k 400.73
# Process time 31s 1ms 10s 32ms 19ms 334ms 16ms
# Request coun 1.97k 1 10 2.02 1.96 0.33 1.96
# Total keys 636.43k 2 103.16k 652.35 793.42 3.97k 400.73
# Txn start ts 374.38E 0 16.00E 375.48P 1.25P 89.05T 1.25P
# Wait time 943ms 1ms 19ms 1ms 2ms 1ms 972us
3.6 系统表
mysql库里存储的是TiDB系统表。该设计类似于MySQL中的mysql库，其中mysql.user之类的表可以直接编辑。该库还包含许多MySQL的扩展表。
1）权限系统表：这些系统表里面包含了用户账户以及相应的授权信息
- user：用户账户，全局权限，以及其它一些非权限的列
- db：数据库级别的权限
- tables_priv：表级的权限
- columns_priv：列级的权限
2）服务端帮助信息系统表
- help_topic 目前为空
3）统计信息相关系统表
- stats_buckets：统计信息的桶
- stats_histograms：统计信息的直方图
- stats_meta：表的元信息，比如总行数和修改数
- GC Worker相关系统表
- gc_delete_range
4）其它系统表
- GLOBAL_VARIABLES：全局系统变量表
- idb：用于 TiDB 在 bootstrap 的时候记录相关版本信息
4、写在最后
TiDB的操作维护相较其它开源数据库如MySQL要简便很多，安装升级等操作基本可以一键完成，同时也能兼容MySQL的大部分功能包括SQL语法、用户权限管理等。有个问题需要后续解惑，TiDB的扩缩容是在后台自动完成的，TiKV数据节点时间相对长一些，也是对用户数据和交易会有影响的，这部分动作不知道是否可以指定时间段手动完成。
参考资料：
转载请注明原文地址：https://blog.csdn.net/solihawk/article/details/118667537
文章会同步在公众号“牧羊人的方向”更新，感兴趣的可以关注公众号，谢谢！
更多推荐
1
0- 0
已为社区贡献3条内容
所有评论(0)