2022年3月1日 第一天
TiDB关键技术创新
- 分层的分布式架构
分布式kv系统
- Local read and geo-partition(跨洲际)
TiDB典型的应用场景
MySQL分库分表，先分表，在分库。
分表主要因为是，数据量起来之后，btree这样的结构高度会增加。高度增加索引的扫描就多一次io。相应时间会变多。
对于mysql的写入是昂贵的代价。主要依赖的都是主库的性能。如果主库的容量放不下了。就需要分库。
中间件主要就是分库分表后对于数据的路由查找。
TIDB是一种HATP的数据库，可以处理OLTP和OLAP的请求。通过不同的引擎来处理不同的需求。
TIDB部署工具-TiUP
- 4.0引入，可以用于部署，启动，关闭，销毁，弹性扩容，升级，管理参数。对于其他的工具tiup也可以管理。
- mac系统或者linux系统才可以使用。windows需要使用虚拟机，机器还需要访问网络下载tiup组件来使用。
- 本地部署集群使用的是TiUP的playgroud组件。与生产的部署不相同，没有集群名，就没法用tidb-cluster去管理。
- 部署完成后，有存储在pd里面的tidb dashboard网页可以来查看监控，当然还有Grafana监控也可以查看
部署命令
tiup playgroud 可以运行最新版本的tidb，其中tidb,tikv,pd,tiflash 实例格1个。
tiup playgroud v5.0.0 --db 2 --pd 3 --kv 3 --monitor 也可以指定版本和实例个数。
tidb的连接
tiup client
mysql --host 127.0.0.1 --port 4000 -u root 刚安装完成的tidb无需密码。
tidb清理
tiup clean -all
TiUP部署练习
1.安装TiUP
[root ~]# curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- 0 0 0 0 0 0 0 0 --:--:-- --:--:-- 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 1 6659k 1 127k 0 0 42696 0 0:02:39 0:00:03 100 6659k 100 6659k 0 0 1793k 0 0:00:03 0:00:03 --:--:-- 1793k
WARN: adding root certificate via internet: https://tiup-mirrors.pingcap.com/root.json
You can revoke this by remove /root/.tiup/bin/7b8e153f2e2d0928.root.json
Successfully set mirror to https://tiup-mirrors.pingcap.com
Detected shell: bash
Shell profile: /root/.bash_profile
/root/.bash_profile has been modified to add tiup to PATH
open a new terminal or source /root/.bash_profile to use it
Installed path: /root/.tiup/bin/tiup
===============================================
Have a try: tiup playground
===============================================
source profile文件，让tiup在哪里都可以使用
[root@ ~]# source /root/.bash_profile
2.部署TiDB
[root@ bin]#
[root@ bin]# ./tiup playground v5.0.0 --db 2 --pd 3 --kv 3 --monitor
tiup is checking updates for component playground ...
A new version of playground is available:
The latest version: v1.9.1
Local installed version:
Update current component: tiup update playground
Update all components: tiup update --all
The component `playground` version is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/playground-v1.9.1-linux-amd64.tar.gz 6.91 MiB / 6.91 MiB 100.00% 13.30 MiB/s
Starting component `playground`: /root/.tiup/components/playground/v1.9.1/tiup-playground /root/.tiup/components/playground/v1.9.1/tiup-playground v5.0.0 --db 2 --pd 3 --kv 3 --monitor
Flag --monitor has been deprecated, Please use --without-monitor to control whether to disable monitor.
Playground Bootstrapping...
Start pd instance:v5.0.0
The component `pd` version v5.0.0 is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/pd-v5.0.0-linux-amd64.tar.gz 41.09 MiB / 41.09 MiB 100.00% 8.66 MiB/s
Start pd instance:v5.0.0
Start pd instance:v5.0.0
Start tikv instance:v5.0.0
The component `tikv` version v5.0.0 is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/tikv-v5.0.0-linux-amd64.tar.gz 161.21 MiB / 161.21 MiB 100.00% 9.33 MiB/s
Start tikv instance:v5.0.0
Start tikv instance:v5.0.0
Start tidb instance:v5.0.0
The component `tidb` version v5.0.0 is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/tidb-v5.0.0-linux-amd64.tar.gz 45.73 MiB / 45.73 MiB 100.00% 7.74 MiB/s
Start tidb instance:v5.0.0
Waiting for tidb instances ready
.......
.......
.......
Waiting for tidb instances ready
The component `prometheus` version v5.0.0 is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/prometheus-v5.0.0-linux-amd64.tar.gz 39.84 MiB / 39.84 MiB 100.00% 10.06 MiB/s
download https://tiup-mirrors.pingcap.com/grafana-v5.0.0-linux-amd64.tar.gz 54.28 MiB / 54.28 MiB 100.00% 6.05 MiB/s
Start tiflash instance:v5.0.0
The component `tiflash` version v5.0.0 is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/tiflash-v5.0.0-linux-amd64.tar.gz 407.93 MiB / 407.93 MiB 100.00% 9.47 MiB/s
Waiting for tiflash instances ready
.......
.......
.......
Waiting for tiflash instances ready
CLUSTER START SUCCESSFULLY, Enjoy it ^-^
To connect TiDB: mysql --comments --host 127.0.0.1 --port 4000 -u root -p (no password)
To connect TiDB: mysql --comments --host 127.0.0.1 --port 4001 -u root -p (no password)
To view the dashboard: http://127.0.0.1:2379/dashboard
PD client endpoints: [127.0.0.1:2379 127.0.0.1:2382 127.0.0.1:2384]
To view the Prometheus: http://127.0.0.1:9090
To view the Grafana: http://127.0.0.1:3000
到这里的时候，就不动了。不要回车，不要ctrl+c 不要有任何操作。开启另外一个ssh窗口来登录即可。
3.连接TiDB/清理集群
通过client连接
[root@ ~]# tiup client
tiup is checking updates for component client ...
A new version of client is available:
The latest version: v1.9.1
Local installed version:
Update current component: tiup update client
Update all components: tiup update --all
The component `client` version is not installed; downloading from repository.
download https://tiup-mirrors.pingcap.com/client-v1.9.1-linux-amd6download https://tiup-mirrors.pingcap.com/client-v1.9.1-linux-amd64.tar.gz 4.05 MiB / 4.05 MiB 100.00% 20.59 MiB/s
Starting component `client`: /root/.tiup/components/client/v1.9.1/tiup-client /root/.tiup/components/client/v1.9.1/tiup-client
Connected with driver mysql (5.7.25-TiDB-v5.0.0)
Type "help" for help.
my:root@127.0.0.1:4000=>
my:root@127.0.0.1:4000=> show databases;
Database
--------------------
INFORMATION_SCHEMA
METRICS_SCHEMA
PERFORMANCE_SCHEMA
mysql
test
(5 rows)
my:root@127.0.0.1:4000=> exit
通过MySQL client连接
[root@ ~]# mysql --host 127.0.0.1 --port 4000 -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 5.7.25-TiDB-v5.0.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA |
| PERFORMANCE_SCHEMA |
| mysql |
| test |
+--------------------+
5 rows in set (0.00 sec)
mysql> exit
Bye
清理tidb集群
[root@ ~]# tiup clean --all
Kill instance of `playground`, pid: 14577
Clean instance of `playground`, directory: /root/.tiup/data/SyoX2Ax
清理完成后，第一个ssh的不动的进程也会停止。
2022年3月2日 第二天
TiDB cluster部署
tiup command 执行命令。
tiup list --installed list是命令，命令作用是打印所有的安装的组件
tiup component 运行组件。
tiup install tidb 命令+组件一起使用。安装tidb组件
1.安装tiup和cluster组件
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source /root/.bash_profile
tiup cluster
2.硬件/系统环境需求
3.系统环境检查
- 操作系统版本检查
- 存储配置检查
- 关闭swap，让tidb运行在内存中
- 安装ntp服务
- 操作系统参数优化
- ssh互信和sudo权限设置
- numactl安装
4.初始化集群拓扑文件
依靠拓扑文件topology.yaml，可以让中控机集中管理部署节点。
一般机器上都有2个文件夹，一个tidb-deploy存放二进制文件和日志，一个tidb-data存放数据.
5.执行部署的相关命令
检查集群存在的潜在风险(部署之前的检查，没有配置互信则需要带-i后边的gcp_rsa来登录检查)
tiup cluster check ./topology.yaml --user root [-p] [-i /root/.ssh/gcp_rsa]
自动修复集群存在的潜在风险(不符合的检查修复)
tiup cluster check ./topology.yaml --apply --user root [-p] [-i /root/.ssh/gcp_rsa]
执行deploy命令部署tidb集群
tiup cluster deploy ${cluster-name} v5.0.0 ./topology.yaml --user root [-p] [-i /root/.ssh/gcp_rsa]
tiup cluster list 列出部署的集群。
tiup cluster display ${cluster=name} 查看指定集群的状态
tiup cluster start ${cluster=name} 启动指定集群，部署完成的cluster是没有启动的。
tiup cluster stop ${cluster=name} 关闭指定集群。
tidb启动的顺序是：pd->tikv->tidb->tiflash
tidb关闭的顺序是：tiflash->tidb->tikv->pd
pd可以理解为大脑。必须先开启，必须最后关闭。
可以通过tidb dashboard或grafana检查集群的状态。
6.使用Tiup部署TiDB cluter 在中控机上安装tiup/cluster组件/升级cluster组件
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source /root/.bash_profile
tiup cluster
tiup update --self && tiup update cluster
tiup --binary cluster 查看cluster组件的版本信息
生成/修改初始化配置文件
tiup cluster template > topology.yaml 生成初始化文件，文件名称topology可以自定义。
vi topology.yaml 写一些配置的文件。按照实际的环境来部署。
tidb cluster 测试部署的使用的是7个服务器来部署的。
pd是3台，tikv是3台。promethus/grafana/altermanager与其中一台pd共用。tidb是1台。
修改配置文件完成后。开始做检查集群
tiup cluster check ./topology.yaml --apply --user root -p
如果没有配置互信，回车之后要输入密码。
然后就会开始对配置文件中的服务器进行部署之前的检查。检查结果为pass/warn的是可以接受的。红色的就不可以接受了。
部署集群
tiup cluster deploy 集群名字 v5.0.0 ./topology.yaml --user root -p
会有一个提示。是否按照指定的配置来安装。直接输入y就可以了。
如果没有配置互信，回车之后要输入密码。
回车之后，下载不同的软件，创建对应的安装目录。然后自动配置和部署。
集群状态检查
tiup cluster list 查看已经部署的集群
tiup cluster display 集群名字 可以查看到节点的信息，是否启动还是关闭状态。还会有datadir和deploydir的展示。
tiup cluster start 集群名 启动集群
mysql -h127.0.0.1 -P4000 -uroot 可以连接到tidb，初始化是没有密码的。必须有mysql客户端。
tiup cluster stop 集群名 关闭集群
tiup cluster display 集群名字
2022年3月4日 第三天
TiDB cluster连接管理
-
tidb负责处理客户端连接和SQL的计算，不存储数据不持久化数据，可以增加tidb节点来提供高并发高负载的均衡，其中一个tidb坏掉，其余的tidb还可以继续提供服务，这就是无状态。
-
支持常见的MySQL命令行客户端和GUI客户端连接，支持MySQL的程序开发接口和API连接。100%兼容mysql5.7，支持5.7版本常用的功能与语法，不支持外键/函数/触发器/主从复制协议等。对于协议使用工具来使用。
连接练习
1.通过mysql客户端和GUI连接TIDB
mysql -h127.0.0.1 -P 4000 -uroot -p
2.一些命令
select tidb_version()\G 查看数据库版本
show databases 查看数据库
create database abc 创建abc数据库
use abc 进入abc数据库
show processlist 查看数据库连接
创建表
create table t1(
id int not null auto_increment,
name varchar(20) not null default '',
age int not ull default 0,
version v,rchar(20) not null default '',
primary key (`id`),
key `idx_age`(`age`)
)
插入数据
insert into t1 values(1,'TIDB',5,'TIDB-V5.0.0');
查询数据
select * from t1;
TiDB cluster参数配置管理
tidb分为系统配置参数和集群配置参数
系统级别参数配置
- 一部分tidb-server参数并存储在数据库tikv中。客户端连接后可以修改并直接生效，不需要重启就可以持久化，重启后不会失效。session作用域的修改只在连接失效前生效。global会话修改后对新的session是生效的老的session不生效。instance修改后只针对当前的这个instance有效。
GLOBAL级别
GLOBAL级别
set global tidb_destsql_scan_concurrency=10; global级别的修改
练习：
mysql> set global auto_increment_increment=10;
Query OK, 0 rows affected (0.00 sec)
mysql> show global variables like 'auto_increment_increment';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 10 |
+--------------------------+-------+
1 row in set (0.00 sec)
mysql> insert into t1 values();
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values();
Query OK, 1 row affected (0.01 sec)
mysql> select * from t1;
+---+
| a |
+---+
| 1 |
| 2 |
+---+
修改了之后对当前的插入是不生效的。
再开启一个新的连接。
mysql> insert into t1 values();
Query OK, 1 row affected (0.01 sec)
mysql> insert into t1 values();
Query OK, 1 row affected (0.01 sec)
新的连接对于global的参数修改已经生效。
mysql> select * from t1;
+----+
| a |
+----+
| 1 |
| 2 |
| 11 |
| 21 |
+----+
4 rows in set (0.00 sec)
global的参数是持久化到tikv的。重启之后发现参数也是10.
SESSION级别
set session(默认的参数，可以不写session) tidb_destsql_scan_concurrency=10; session级别的修改
练习：
show session variables like 'auto_increment_increment'
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 1 |
+--------------------------+-------+
创建表
create table t(a int not null primary key auto_increment);
插入数据
insert into t values();
insert into t values();
查询数据
mysql> select * from t;
+---+
| a |
+---+
| 1 |
| 2 |
+---+
更改session级别的参数
set session auto_increment_increment=10;
插入数据
insert into t values();
insert into t values();
查询数据
mysql> select * from t;
+----+
| a |
+----+
| 1 |
| 2 |
| 11 |
| 21 |
+----+
4 rows in set (0.01 sec)
打开另一个会话
插入数据
insert into t values();
insert into t values();
查询数据
mysql> select * from t;
+----+
| a |
+----+
| 1 |
| 2 |
| 11 |
| 21 |
| 22 |
| 23 |
+----+
6 rows in set (0.00 sec)
看出来参数只对当前的session生效。
集群配置
- 包含pd，tikv，另一部分的tidbserver的参数，参数都存放在各自节点的配置文件中，通过修改参数文件重启后才可以生效，必须通过tiup edit-config和tiup reload进行修改。对所有的节点都是生效的。
编辑模式打开集群的配置文件
tiup cluster edit-config 集群名字
tiup cluster reload 集群名字
show config 可以查看集群所有实例的配置信息
例子：修改所有TiKV的节点配置，将日志等级从info(全部记录)改为warning(只记录警告)
TiKV的配置文件一般在deploy/tikv-20160/conf/tikv.toml
1.修改配置文件
tiup cluster edit-config 集群名
在global配置下边写入server_configs来配置。对于这样的配置对所有的tikv节点都有效，不用单独修改每一个tikv的参数。
global:
user:tidb
....
....
server_configs:
tidb:{}
tikv:
log-level：warning
输入esc，使用wq来退出，会有一个提示，对于高亮部分的修改是否应用。输入y即可。
2.重启节点
tiup cluster reload 集群名
用来重启节点，来让参数生效。
对于重启的时候，tidb不会存在不可用的情况。因为会先停止一个。然后将读写的请求都发给leaders。滚动式的重启，保证最少有一个可以读写。但是对性能是有影响的。会转移读写。
重启完成之后，在去节点查看配置文件会发现。修改已经持久化到了配置文件中。
2022年3月7日 第四天
TiDB 用户管理
认证就是能不能联到数据库，授权就是对库和表又没有权限。 查看用户，创建用户和授权跟mysql一毛一样
1.查看所有用户()
mysql> select user,host,authentication_string from mysql.user;
+---------------+-----------+-------------------------------------------+
| user | host | authentication_string |
+---------------+-----------+-------------------------------------------+
| root | localhost | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 |
+---------------+-----------+-------------------------------------------+
2.授权grant/回收revoke/删除
grant all on *.* to 'user'@'%' with grant option;
revoke all on *.* from 'user'@'%';
drop user 'user'@'%'
3.修改密码
set password for 'user'@'%'='newpass';
alter user 'user'@'%' identified by 'newpass;
4.修改文件
[security]
skip-grant-table=true
重启之后生效可以修改密码。
TiDB 文件与日志管理
tidb：二进制文件(bin),配置文件,日志文件 pd:二进制文件(bin),配置文件，日志文件，数据文(生产的数据) tikv：二进制文件(bin),配置文件，日志文件，数据文件(元数据)
查看配置文件在哪里
tiup cluster edit-config 集群名
其中deploy_dir表示节点软件目录，data_dir表示节点的数据目录。log_dir表示日志所在的目录。
TiDB 监控管理
grafana+prometheus http://{grafana服务器ip地址}:3000来访问 初始的账户密码admin/admin Prometheus里面有一个时序数据库，通过拉取每个节点的监控数据存放在时序数据库中，。grafana通过查询prometheus的时序数据来展示给用户，对于时序数据达到设定的阈值后，prometheus将告警发送给用户。 报警级别： 警告：某一个问题或错误提醒。 严重：影响性能，需要关注的指标 紧急：服务不可用，节点停止或者故障，需要马上人工干预。 通过对指标的阈值进行设置。然后到达了这个阈值报警去处理即可。
常用的监控指标： 首先看 system-info cpu配置/内存配置/网络状态/cpu使用率/内存使用率 service port status 查看节点是否存活。
pd常用指标 总大小，使用大小，regions数，是否有错误。 最重要的看region监控信息。对于不同颜色的线要进行不同的处理。蓝色的线是正常的。
tidb-server常用指标 每秒执行SQL数/SQL平均处理时间(客户端连接，tidb处理返回。如果平均时间比较大，证明这个阶段是有问题的。有大查询或阻塞，很容易发现问题。)/连接数/内存使用量
tikv-server常用指标 leader数量(数据是否均衡)/region数量/cpu负载/内存使用量
Tidb_dashboard http://{pd-ip}:2379/dashboard 初始账户与密码root/ 4.0版本提供的图形化界面。用于监控和诊断。没有告警。部署到了pd中无需独立部署。开启pd就有这个页面。 提供：
- 集群运行状态(TPS/组件状态/SQL执行状态)
- 组件和主机的状态(每个节点的cpu/内存/网络/io)
- 集群读写流量的分布和趋势(通过了热力图，发现业务模式的变化)
- 列出耗时SQL的执行信息/时间较长的SQL的执行信息(定位最消耗资源的SQL/找到慢SQL)
- 诊断问题生成报告(通过对基线的比对。来报告问题)
- 查询所有组件日志(统一管理不同节点的日志。)
- 收集分析各个组件的性能数据(高级调优，无需第三方插件对组件性能分析)
第一眼看cluster info 对于instance查看当前的组件是否存活，是否up。 再看hosts查看组价当前的资源使用(cpu/内存)情况。 QPS，查看那一段时间qps比较多，是业务比较繁忙或者业务阻塞了？ 延迟，在某个时间出现延迟是SQL的问题还是业务的问题？来定位原因。
2022年3月21日 第五天
TiDB 集群管理
1.在线扩容TIKV节点/缩容TIKV节点
在线扩容
1.观察tidb cluster状态
tiup cluster display clustername
2.编辑扩容文件 scale-out-tikv.yaml
tikv_servers: #添加什么节点一定要在前边注明
- host:ip
ssh_port:22
port:20160
status_port:20180 #日志端口
deploy_dir:/tidb-deploy/tikv-20160
data_dir:/tidb-data/tikv-20160
log_dir:/tidb-deploy/tivk-20160/log
3.通过TIUP执行扩容(自动部署)
tiup cluster scale-out clustername scale-out-tikv.yaml -uroot -p
4.检查tidb cluster状态
tiup cluster display clustername
在线缩容
1.执行命令
tiup cluster scale-in clustername --node ip 20160
将数据转以后，让节点下线
2.观察tidb cluster状态
tiup cluster display clustername
会发现刚才缩容的tikv节点的状态是Tombstone
3.在集群中清理已经下线节点的信息。
tiup cluster prune clustername
2.在线扩容TiFlash/在线缩容TiFlash
扩容TiFlash
1.确认当前版本是否支持TiFlash。4.0以上版本才支持，如果低版本建议升级之后在使用。
2.打开enable-placement-rules 参数(PD的一个参数)
3.编辑扩容文件
vi scale-out-tiflash.yaml
4.执行扩容命令
tiup cluster scale out clusername scale-out.yaml
5.确认集群的状态
tiup cluster display clustername
缩容TiFLash
1.根绝Tiflash剩余节点数调整数据表的副本数
alter table dbname tablename set tiflash replica 0;
2.确认表的副本已经被删除
select * from information_schema.tiflash_replica where table_schema='dbaname'
and table_name='tablename'
3.查看集群状态
tiup cluster display clustername
4.执行缩容命令
tiup cluster scale-in clustername --node ip port
5.查看集群状态
tiup cluster display clustername
3.修改集群名
1.执行命令即可
tiup cluster rename oldclusername newclustername
2.观察tidb cluster状态
tiup cluster display newclustername
集群会重启监控，监控中可能会存在一些旧的集群的面板，删除即可。
4.清理集群数据/重构集群(清理不可逆，无法恢复)
1.清理集群数据(清理日志，清理数据，清理日志和数据)
tiup cluster clean clustername --log
tiup cluster clean clustername --data
tiup cluster clean clustername --all
2.重构集群
销毁集群
tiup cluster destroy clustername
重建集群
与最初部署的命令是一致的。
TiDB 升级管理
1.补丁升级(Hotfix)
升级集群上所有的tidb实例
tiup cluster patch clustername /tmp/tidb-hotfix.tar.gz -R tidb
一个一个升级也可以
tiup cluster patch clustername /tmp/tidb-hotfix.tar.gz -N ip port
2.版本升级(4.0升5.0)
- 3.0之前的版本，升级到4.0后在升级到5.0.不可以跨版本升级
- 首选升级tiup。版本建议不低于1.4
升级tiup版本
tiup update --self
升级tiup cluster版本
tiup update cluster
- 修改tiup cluster拓扑文件，将旧版本支持的新版本不支持的参数去掉，新版本独有参数要添加进去如果使用的是是系统默认的参数可以不修改。
tiup cluster edit-config clustername - 通过check检查集群健康状态。检查的是regions。成功会返回all regions healthy才可以升级
tiup cluster check clustername --cluster - 升级到指定版本(默认是不停机升级，会对性能有影响但是可以提供服务。停机升级更快速)
不停机升级(不建议在业务繁忙期间升级)
tiup cluster upgrade clustername version
对当前的性能会有影响，将当前的leader读写的region切换，然后升级重启。滚动升级。
停机升级(如果有停机的发版时间，建议停机升级)
停止集群
tiup cluster stop clustername
离线升级
tiup cluster upgrade clustername version --offline
启动升级
tiup cluster start clustername
- 验证
- 升级的常见问题
升级报错
1.报错中断。处理后如何再次升级
查看操作记录，知道失败的升级操作记录id
tiup cluster audit
2.重试上次的升级操作记录
tiup cluster replay audit-id
升级等待时间过。跳过该步骤快速升级
tiup cluster upgrade clustername version --force
周边工具的升级,比如升级pt-ctl到5.0
tiup install ctl:v5.0.0
升级例子:
4.0升级到5.0
1.检查状态
tiup cluster display clustername
2.升级
tiup cluster upgrade clustername v5.0.0
3.检查状态
tiup cluster display clustername
2022年3月23日 第六天
TiDB 物理备份与恢复
- 逻辑备份使用dumpling备份，使用tidb lightning来恢复。转存SQL语句，适合数据量比较小的备份需求。因为是sql语句形式。可以恢复到任何其他的数据库上。转储过程中可能有锁阻止修改数据。
- 物理备份使用br，属于热备份，直接复制二进制文件来实现，更快速，复制的文件副本与原文件大小相同。在备份同时通过mvcc保证一致性。适用于大数据量的备份需求。备份文件只能恢复到tidb中。在业务低峰期备份。备份期间，服务器不得修改数据文件，实时复制文件，防止写入这些文件。还可以通过快照和从库来降低对主库的影响。
- 复制方式，类似于mysql的主从复制，因为是异步复制，有一定的延迟性。
- 操作拷贝，当前tidb无法提供服务。更快速。但一般不会使用。
官方的分布式备份恢复工具，对tidb集群进行数据备份和恢复。属于热备份。拷贝出的文件是SST文件，只能恢复到Tidb。建议部署在pd节点上，br已经集成在Tidb-toolkit中。要是用先下载tidb-toolkit。
wget https://download.pingcap.org/tidb-community-toolkit-v5.0.4-linux-amd64.tar.gz
tar xf tidb-community-toolkit-v5.0.4-linux-amd64.tar.gz
cd tidb-community-toolkit-v5.0.4-linux-amd64.tar.gz/bin
BR备份/恢复原理
在备份/恢复过程中。主要作用于Tikv节点。
每个Tikv节点都有一个对应的备份目录，可以是本地可以是外部的存储。每个tikv都必须创建，且必须为空否则报错。
br backup xxx /br restore xxx
当执行命令时候，相应的tikv的备份文件都会保存在每个tikv节点对应的备份路径内。
恢复的时候，会从每个tikv的备份路径下读取相应的备份文件。
备份执行的时候。每个tikv会备份自己的数据将sst文件复制到备份路径里面，用底层的rocksdb直接把文件拷贝出来，通过mvcc保持一致性。适用于数量大要求速度的需求。
每个节点region的leader是不同的。所以备份出来的sst文件数量也不相同。
备份完成后会有状态返回来提示是否成功，也可以通过查看备份日志来发现错误在哪里。
在恢复的时候每个tikv的备份目录必须有所有的备份文件
比如有A,B,C3个tikv，分别有1,5,10个备份sst文件分别存放在各自的tikv指定的备份目录下。
在恢复的时候。A/B/C的备份目录里面必须分别都有16个sst文件。需要将其他节点的备份文件拷贝到自己的备份目录下。A,B,C都是16个备份文件后，才可以进行恢复。
如果挂载了共享存储，备份后就都在一个文件夹中，恢复的时候也不需要分别复制sst文件。
BR的限制
- 在A集群恢复数据的时候，如果B集群使用TICDC/DRAINER同步A集群。则恢复的数据无法通过TICDC/DRAINER同步到B集群上，只能A恢复完成后再使用TICDC/DRAINER，或者使用dumpling/tidb lightning来同步。
- A集群备份，恢复到B集群，两个集群必须采取系统排序规则,查询new_collations_enabled_on_first_booststrap来查看是否是相同的排序规则。因为备份恢复的kv的数据，排序不同会出错。
- br在备份会检查版本，如果br是4.0。tidb cluster是5.0的就会退出备份，可以使用-check-requirements=false 来跳过版本检查。但是备份会有兼容性的问题。
- 特定的功能在开启和关闭状态下，导致kv的格式发生变化,参考文档来查看即可。
- br需要1c，4GB，HDD,千兆网卡的最低配置(表小于1000张)。
- 可以使用sql语句和br命令行来备份， show backups/br backup
全库备份/恢复
br backup full \
--pd "pdip:2379" \
--storage "local:///tmp/backup" \
--ratelimit 120 \
--log-file backupfull.log
先把备份文件复制到全部的tikv节点的备份目录下，保证每个tikv有所有的备份文件后再进行恢复。
tikv1：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv2：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv1/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv2/tmp/backup
br restore full \
--pd "pdip:2379" \
--storage "local:///tmp/backup" \
--ratelimit 120 \
--log-file restorefull.log
pd: 可以选择任何一个节点
storage: 使用外部的存储，存放在每个Tikv指定的备份目录
ratelimit: 限制备份与恢复时的速度，但是是每秒多少mb
log-file: 记录备份和恢复的日志
restore storage:这个文件夹下，一定是全部的tikv的备份文件，而不是单个本节点的tikv的备份文件。
单库备份/恢复
br backup db \
--pd "pdip:2379" \
--db test \
--storage "local:///tmp/backup" \
--ratelimit 120 \
--log-file backupfull.log
先把备份文件复制到全部的tikv节点的备份目录下，保证每个tikv有所有的备份文件后再进行恢复。
tikv1：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv2：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv1/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv2/tmp/backup
br restore db \
--pd "pdip:2379" \
--db "test"
--storage "local:///tmp/backup" \
--log-file restorefull.log
单表备份/恢复
br backup table \
--pd "pdip:2379" \
--db test \
--table usertable \
--storage "local:///tmp/backup" \
--ratelimit 120 \
--log-file backupfull.log
先把备份文件复制到全部的tikv节点的备份目录下，保证每个tikv有所有的备份文件后再进行恢复。
tikv1：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv2：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv1/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv2/tmp/backup
br restore table \
--pd "pdip:2379" \
--db "test" \
--table usertable \
--storage "local:///tmp/backup" \
--log-file restorefull.log
过滤恢复数据
使用复杂的过滤条件恢复多个表，在全库备份的情况下使用--filter 或者-f来指定库表来恢复。
先把备份文件复制到全部的tikv节点的备份目录下，保证每个tikv有所有的备份文件后再进行恢复。
tikv1：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv2：scp /tmp/backup/*.sst root@tikv3/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv1/tmp/backup
tikv3：scp /tmp/backup/*.sst root@tikv2/tmp/backup
br restore full \
--pd "pdip:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--log-file restorefull.log
增量备份/恢复
只需要在备份的时候指定上一次的备份时间戳 --lastbackupts即可。全备份和增量备份要不在同一目录下恢复与全库恢复方法一致，先恢复全库，在恢复增量即可。 需要把全备份和增来备份的备份文件复制到各个tikv节点。保证tikv每个节点都有所有的备份文件。才继续恢复。
br backup full \
--pd "pdip:2379" \
-s local:///tmp/backup/incr \
-- lastbackups ${LAST_BACKUP_TS}
获取时间戳方式
LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///tmp/backup/ | tail -n1`
BR工具建议
- 在业务低峰期备份和恢复，并建议低峰或者限速来恢复。
- 备份和恢复建议串行执行。不要并行执行。
- 推荐--storage 指定的备份路径上挂在一个高吞吐的共享存储。
TiDB 逻辑备份与恢复
1.逻辑备份 dumpling
- 支持sql/csv格式，逻辑导出
- 支持表过滤和数据过滤。
- 可以导出到 Amazon s3云盘
- 针对tidb 进行优化,保证一致性。
- 适用于数据量小，适用于异构的系统迁移，导出效率不高。
- 只有全量导出。
- 通过tiup install dumpling / tidb-toolkit 来获得。
- 需要select,reload,lock tables,replication client 权限。
- 可以导出tidb和mysql/mariadb的数据。因为dumpling是客户端工具。导出的文件都相同有DLL语句sql文件和数据sql文件
导出示例:
dumpling -u root -p -P 4000 -h 127.0.0.1 --filetype sql --threads 32 -o /tmp/test -r 200000 -F 256MiB
dumpling -u root -p -P 4000 -h 127.0.0.1 -o /tmp/test --where "id < 100"
dumpling -u root -p -P 4000 -h 127.0.0.1 -o /tmp/test -r 200000 --filter "employees.*" --filter "*.Workorder"
dumpling -u root -p -P 4000 -h 127.0.0.1 -o /tmp/test -r 200000 -B employees
dumpling -u root -p -P 4000 -h 127.0.0.1 -o /tmp/test -r 200000 -T employees.Workorder
--filetype 可以是sql可以是csv
--threads/-t 并发执行导出的线程数,更快并发，但是会消耗内存不建议特别大。
-o 存放文件的目录
-r 单个文件最大的行数
-F 单个文件的最大大小
对于单个数据文件大于10G，建议加上-r和-F参数。可以并发的导出。
--where 对数据进行筛选，只能用于csv文件，对所有的表进行过滤。需要保证每个表都有id这一列。
--filter 也可以进行筛选。指定库和表。
-B 指定库导出
-T 指定表导出
导出的文件格式：
导出会生成4个文件
比如导出world下city这张表
metadata 包含导出起始时间，以及master binary log的位置
world-schema-create.sql 内容是创建库的DDL语句
world.city-schema.sql 内容是创建表的DDL语句
wolrd.city.00000000100000.sql 表的数据
导出world库。包含库级别的ddl语句，每张表自己的DDL语句文件和数据文件。1张表会生成2个sql文件。
metadata 包含导出起始时间，以及master binary log的位置
world-schema-create.sql 内容是创建库的DDL语句
world.city1-schema.sql 内容是创建表的DDL语句
wolrd.city1.00000000100000.sql 表的数据
world.city2-schema.sql 内容是创建表的DDL语句
wolrd.city2.00000000100000.sql 表的数据
导出的一致性
通过--consistency level 控制一致性的方式
flush 备份前，执行flush table with read lock 只读不可写。
snapshot 默认，指定一个时间的数据备份，就算你备份的时候数据被删除了。也可以依靠mvcc来完成导出。
lock 备份那个表锁那个表。
none 不用
auto 如果是tidb使用snapshot，如果是mysql或者mariadb使用flush。
dumpling --snapshot 41777777983948092834
dumpling --snapshot "2022-07-02 17:17:17"
2.逻辑恢复 TiDB Lightning 将全量数据高速导入到TiDB集群中。
- 在导入之前，tidb-lightning自动将tikv-server切换为导入模式。优化写入，停止数据的压缩，导入效率高，影响线上业务的可读性。不要再繁忙期进行。
- tidb-lightning首先在目录集群的tidb-server(负责sql的执行)上将库和表建立起来。
- 假如200Gb的表，当前对表进行分割。分割成一快一块的区块。比如256M一块区块。可以做增量方式的并行导入。
- 还会在pd上获取元数据，指导导入。
- 把切好的文件并发的读取，转换为kv键值对。排好序存入到tikv的本地存储。
- 把本地存储的kv键值对，加载到tikv-server上。并校验与分析是否成功。
- 变为普通模式。如果在某一步失败了。记得将导入模式手动切换为普通模式。
- 适用于大量新数据写入的场景，最高支持每小时400G-500G的快速导入。50G/每小时的事务型导入
- 支持dumpling，csv，Amazon aurora qarquet输出的数据源
- 本地盘/s3 云盘读取数据。
- 硬件需要32+C,20GB,SSD(假如源数据1个T，则需要x3因为region有3份，还需要x2因为在导入的时候生成了临时的文件一份，导入后生成的文件1份。所以1T源数据需要6T的空间SSD),万兆网卡/带宽1GB/s,建议单独部署
- 权限需要dml+create,drop,alter
- 通过tiup install lightning / tidb-toolkit 来获得。
- 有三种后端模式
- local-backend 4.0之后使用的。优先考虑。
- import-backend，4.0之前使用的，先变为kv键值对，在通过tikv-importer来导入。需要多一个环节。兼容所有版本，3.0版本优先考虑。
- tidb-backend 连接到tidb,执行insert语句导入，可以支持事务，但是比较慢。也兼容所有版本。线上环境表已经有数据了。使用这种模式比较好。
导入数据的时候需要配置一份参数文件
cat tidb-lightning.toml
[lightning]
#默认是逻辑cpu数量，如果混合部署的话调整为cpu的75%的大小即可。
#region-concurrency=
#日志
level="info"
file="tidb_lightning.log"
[tikv-importer]
#是指backend模式
backend="local"
#本地临时存储目录
sorted-kv-dir="/ssd/sorted-kv-dir"
[mydumper]
#源数据目录，也就是备份文件的目录
data-source-dir="data/my_database"
[tidb]
#目标集群的信息，tidb-server指定一个即可。
host=
port=
user=
password=
#表架构信息在tidb的状态端口获取
status-port=10080
#pd-server地址，指定一个即可。
pd-addr="ip:port"
信息修改完成后，可以执行。建议脚本执行，导入完成后tidb lightning会自动退出，nohup.out文件输出tidb lightning exit为导入正确。
#!/bin/bash
nohup tidb-lightning -config tidb-lightning.toml > nohup.out &
断点传输
[checkpoint]
#启动断点传输,会记录当前进度，如果出现异常，重启后可以避免在导入已完成的数据。
enable=true
断点的存储
#file 存放在本地文件系统
#mysql 存放在兼容mysql的数据库服务器
driver="file"
断点续传控制，如果lightning出现了不可恢复的错误，比如是数据错误，则不会使用断点的进度
--checkpoint-error-destory: 对失败的表重头开始导入整个过程。
--checkpoint-error-ignore: 清楚错误状态，忽略错误继续导入，all代表对所有表进行如上操作
--checkpoint-remove:无论是否出错，把表的断点清楚。
数据过滤
只导入abc或者xyz开头的所有库和所有表
tidb-lightning -f "abc*.*" -f 'xyz.*.*' -d /tmp/data/ --backend tidb
[mydumper]
fileter=['abc*.*','xyz.*.*']
WEB管理界面
1.启动服务
tidb-lightning --server-mode --status-addr :8299
[lightning]
server-mode=true
status-addr=':8299'
2.提交任务
3.查看导入进度
4.管理任务
2022年3月24日 第七天
TiDB DM 数据迁移工具
Data Migration
- 支持mysql/mariadb/Aurora Mysql到Tidb的数据迁移。
- 支持全量的迁移和增量的传输
- 对表和操作进行过滤，比如只传输A表不传输B表，只传输insert不传输delete
- 对于已经分库分表的mysql。DM可以进行合并迁移。
- 适用于源库表与目标库异构表的迁移
- 异步迁移，源端事务提交后，目标端才能迁移。
流程：
-
通过dmctl接口操作管理dm。创建更新删除任务，查看任务状态，处理错误。
-
dm-master收到dmctl的命令。负责协调和分配dm-worker任务。保存着dm的拓扑信息，负责dm-worker的高可用，可以监控dm-worker的运行状态。dm-master和dm-worker都是高可用的。一个故障，其他空闲的直接替代继续服务。
-
dm-worker收到具体任务后，通过对源端mysql/mariadb的binlog日志的读取，保存到dm-wokrer本地后进行编排并写入到Tidb cluster中。每个dm-worker只负责一个源端。
使用tiup部署dm集群
编辑初始化文件
tiup dm template > topology.yaml 直接生成模板
直接修改模板中的相应的信息即可。
cat topology.yaml
lobal:
user: "tidb"
ssh_port: 22
deploy_dir: "/home/tidb/dm/deploy"
data_dir: "/home/tidb/dm/data"
# arch: "amd64"
master_servers:
- host: 172.2.1.1
- host: 172.2.1.2
- host: 172.2.1.3
worker_servers:
- host: 172.2.1.1
- host: 172.2.1.2
- host: 172.2.1.3
monitoring_servers:
- host: 172.2.1.1
grafana_servers:
- host: 172.2.1.1
alertmanager_servers:
- host: 172.2.1.1
查看最新版本的dm
tiup list dm-master
执行部署命令
tiup dm deploy dmname(随便起一个名字) 最新版本 ./topology.yaml --user root -p
查看dm集群(tiup可以管理多个dm)
tiup dm list
查看dm集群的状态
tiup dm display dmname
启动dm集群
tiup dm start dmname
DM的配置
- MySQL要开启binlog
- Data Filter，指定那些库和表要同步，binlogevent指定那些操作要同步
- table routing ,表映射(假设源端叫t1,目标端叫s1，就依靠路由来处理)，处理分库分表(源端2个分片m1m2，tidb是m。也由路由来映射将m1m2同步到m)
- tidb，binlog转换为kv，并行分块等等。
示例：
源端的mysql需要配一个文件，名字随便写，比如source.yaml
cat source.yaml
#对源数据源起一个名字
source-id: "mysql-replica-01"
#是否开启gtid
enable-gtid: false
#是否开启relay log，拉取时自己记不记日志
enable-relay: false
#拉取上游binlog的起始文件名
relay-binlog-name: ''
#拉取上游binlog的起始GTID
realy-binlog-gtid: ''
from:
host："10.1.1.1"
port: 3306
user: "root"
password: "mima"
将数据源载入到dm里面
tiup dmctl --master-addr(pd的ip) operate-source create source.yaml
有了数据源开始配置任务
cat task.yaml
#任务名字，多个同时运行的不能重名
name: "test"
#迁移模式,全量+增量=all
task-mode: "all"
#目标端Tidb的配置信息
target-database:
host: "172.1.1.1"
port: 4000
user: "root"
password: ""
#规则配置
mysql-instances:
#从哪个源端迁移数据
- source-id: "mysql-replica-01"
#对库表的过滤规则
block-allow-list: "bw-rule-1"
#对binlog的event的过滤规则，可以有多个
filter-rules: ["filter-rule-1"]
#迁移到目标端tidb表的路由规则，可以定义多个规则
route-rules: ["root-rule-1","route-rule-2"]
- source-id: "mysql-replica-02"
block-allow-list: "bw-rule-2"
filter-rules: ["filter-rule-2"]
#库表的过滤规则
block-allow-list: #定义数据源迁移规则，如果dm版本是2.0之前的使用
black-white-list
bw-rule-1: #规则名称
do-dbs: ["user"] #迁移那些库
ignore-dbs: ["test"] #忽略那些库
do-tables: #迁移那些表
- db-name: "user"
tbl-name: "t1"
#event的过滤规则
filters:
filter-rule-1:
schema-pattern: "test" #库名匹配规则，支持*和？
table-pattern: "sbtest" #表名匹配规则，支持*和？
events: ["insert"] #匹配那些event
action: Ignore #对符合规则的binlog迁移是do还是ignore
filter-rule-2:
schema-pattern: "test"
events: ["truncate table"] #test库下所有的truncate table都不会复制到目标端。
action: Ignore
#table routing
routes:
route-rule-1:
schema-pattern: "test" #库名匹配规则，支持*和？
table-pattern: "sbtest1" #表名匹配规则，支持*和？
target-schema: "test" #目标库名称
target-table: "sbtest2" #目标表名称,没有也会自动创建
分库分表合并迁移
源端sales有一张分片表在不同的实例中，or1 or2 or3 .希望迁移到sales的order表中 可以同过table routing来设置
routes:
sales-route-rule:
schema-pattern: "sales"
table-pattern: "or*"
target-schema: "sales"
target-table: "order"
检查与启动任务
检查任务
tiup dmctl --master-addr 172.1.1.1:8261 check-task ./task.yaml
启动任务
tiup dmctl --master-addr 172.1.1.1:8261 start-task ./task.yaml
暂停任务
tiup dmctl --master-addr 172.1.1.1:8261 pause-task ./task.yaml
恢复任务
tiup dmctl --master-addr 172.1.1.1:8261 resume-task ./task.yaml
查询任务状态
tiup dmctl --master-addr 172.1.1.1:8261 query-status dmname
停止任务
tiup dmctl --master-addr 172.1.1.1:8261 stop-task dmname
性能优化
全量导出
rows 单表多线程的导出，按照一块一块导的。可以设置为10000根据mysql的新能来调整。还需要设置threads来设置并发的线程数默认是4.每一个线程读取的是表的一个chunk，rows就是一个chunk里面的行数。
chunk-filesize dm在做全量导出的时候根据这个值将表分成多个chunk，每一个chunk保存在一个文件中，dm可以并发导出多个chunk。默认值是64MB
全量导入
pool-size dm导入到Tidb的并发线程数。默认是16
增量复制
worker-count 目标Tidb下dm-worker并发在itidb执行sql的线程数。默认是16个
batch 目标端tidb每个事物包含的dm数量。默认是100，把大事务拆成多个小事务。
DM常见问题
- 只兼容部分DDL。对一些不支持的ddl出错，使用如下命令跳过即可。 `tiup dmctl --master-addr 172.1.1.1:8261 handle-error dmname skip '
- 自增主键冲突处理,主要出现在分库分表合并的场景中。建议去掉自增主键的主键属性/使用联合主键，再加一列标识是那个分片的。
- mysql5.5以上，mariadb10.1.2以上支持。
- 对于dm访问的是vip不是真实的数据库地址，在故障切换后，会出现与预期拉取数据不一致的情况。M可能binlog读到了20，S可能切换才是1.这个时候需要手工转换一下。
示例
- 安装dm
- 同步3306 3307的数据。具体的同步规则查看task.yaml
1.安装dm
tiup install dm
2.更新dm,建议tiup使用1.5.1。1.5.0安装启动dm会出错
tiup update --self && tiup update dm
3.生成部署文件
tiup dm template > topology.yaml 直接生成模板
4.修改部署文件中的信息
cat topology.yaml
lobal:
user: "tidb"
ssh_port: 22
deploy_dir: "/home/tidb/dm/deploy"
data_dir: "/home/tidb/dm/data"
# arch: "amd64"
master_servers:
- host: 172.2.1.1
- host: 172.2.1.2
- host: 172.2.1.3
worker_servers:
- host: 172.2.1.1
- host: 172.2.1.2
- host: 172.2.1.3
monitoring_servers:
- host: 172.2.1.1
grafana_servers:
- host: 172.2.1.1
alertmanager_servers:
- host: 172.2.1.1
5.查看最新版本的dm
tiup list dm-master
6.执行部署命令
tiup dm deploy dm-test v5.0.0-nightly-20210531 ./topology.yaml --user root -p
7.查看dm集群(tiup可以管理多个dm)
tiup dm list
8.查看dm集群的状态
tiup dm display dmname
9.启动dm集群
tiup dm start dmname
10.登录mysql数据库创建用户,测试环境给与all权限，详细权限查看文档来赋权限。3306 3307都执行。
create user root@'%' identified by '123456'
grant all on *.* to root@'%';
11.导入特定的数据库和数据 user,store,log,salesdb 3306 3307执行
3306和3307是分库分表。
12.在tidb上创建用户。测试环境给与all权限，详细权限查看文档来赋权限。在一个tidb 4000上执行
create user root@'%' identified by '123456'
grant all on *.* to root@'%';
13.在目标端tidb上创建数据库,也可以不预先创建，dm在同步之前会创建库和表
# 同步3306
create database user_north;
create table infomation(id int primary key,info varchar(64));
create table trace(id int primary key,content varchar(64));
# 同步3307
create database user_east;
create table infomation(id int primary key,info varchar(64));
create table trace(id int primary key,content varchar(64));
# 同步33063307
create database store;
create table store_bj(id int primary key,pname varchar(64));
create table store_tj(id int primary key,pname varchar(64));
create table store_sh(id int primary key,pname varchar(64));
create table store_suzhou(id int primary key,pname varchar(64));
#同步33063307,分库分表，将数据合并同步
create database salesdb;
create table store_bj(id int primary key,pname varchar(20),cnt int);
create database log;
create table messages(id int primary key,msg varchar(64));
14.编辑数据源文件
使用tiup dmctl -encrypt '123456' 将明文密码加密
cat 3306.yaml
source-id: "mysql-replica-01"
from:
host："10.1.1.1"
port: 3306
user: "root"
password: "加密后的密码"
cat 3307.yaml
source-id: "mysql-replica-02"
from:
host："10.1.1.1"
port: 3307
user: "root"
password: "加密后的密码"
15.加载数据源到dm.任选一个pd节点即可。
tiup dmctl --master-addr=172.1.1.1:8261 operate-source create 3306.yaml
tiup dmctl --master-addr=172.1.1.1:8261 operate-source create 3307.yaml
查看已加载数据源的状态
tiup dmctl --master-addr=172.1.1.1:8261 get-config source 3306.yaml
tiup dmctl --master-addr=172.1.1.1:8261 get-config source 3307.yaml
查看数据源与dm-worker的对应关系
tiup dmctl --master-addr=172.1.1.1:8261 operate-source show
16.配置任务文件
cat dm-task.yaml
#任务名字，多个同时运行的不能重名
name: "dm-taskX"
task-mode: "all"
ignore-checking-items: ["auto_increment_ID"] #忽略主键检查
#目标端Tidb的配置信息
target-database:
host: "172.1.1.1"
port: 4000
user: "root"
password: ""
#规则配置
mysql-instances:
- source-id: "mysql-replica-01"
block-allow-list: "log-ignored"
filter-rules: ["trace-filter-rule","user-filter-rule","store-filter-rule"]
route-rules: ["instance-1-user-rule","sale-route-rule"]
mydumper-config-name:"global"
loader-config-name:"global"
syncer-config-name:"global"
- source-id: "mysql-replica-02"
block-allow-list: "log-ignored"
filter-rules: ["trace-filter-rule","user-filter-rule","store-filter-rule"]
route-rules: ["instance-2-user-rule","instance-2-store-rule","sale-route-rule"]
mydumper-config-name:"global"
loader-config-name:"global"
syncer-config-name:"global"
#库表的过滤规则
block-allow-list: #定义数据源迁移规则，如果dm版本是2.0之前的使用
log-ignored:
ignore-dbs: ["log"]
#event的过滤规则
filters:
trace-filter-rule:
schema-pattern: "user"
table-pattern: "trace"
events: ["truncate table","drop table","delete"] #匹配那些event
action: Ignore
user-filter-rule:
schema-pattern: "user"
events: ["drop database"]
action: Ignore
store-filter-rule:
schema-pattern: "store"
events: ["drop database","truncate table","drop table","delete"]
action: Ignore
#table routing
routes:
instance-1-user-rule:
schema-pattern: "user" #库名匹配规则，支持*和？
target-schema: "user_north" #目标库名称
instance-2-user-rule:
schema-pattern: "user" #库名匹配规则，支持*和？
target-schema: "user_east" #目标库名称
instance-2-store-rule:
schema-pattern: "store" #库名匹配规则，支持*和？
table-pattern: "store_sz" #目标库名称
target-schema: "store" #库名匹配规则，支持*和？
target-table: "store_suzhou" #目标库名称
#分库分表，直接汇总数据到目标端
sale-route-rule:
schema-pattern: "salesdb" #库名匹配规则，支持*和？
target-schema: "salesdb" #目标库名称
mydumpers:
global:
threads:4
chunk-fileszie:64
17.检查任务
tiup dmctl --master-addr 172.1.1.1:8261 check-task ./dm-task.yaml
18.启动任务
tiup dmctl --master-addr 172.1.1.1:8261 start-task ./dm-task.yaml
19.查询任务状态
tiup dmctl --master-addr 172.1.1.1:8261 query-status dm-task.yaml
20.验证目标端Tidb数据
测试表的数据是否增量的拉取。
测试event是否被忽略
测试log库到底有没有拉取。
暂停任务/恢复任务可以将数据继续拉取过来。停止任务就不会再续传。
DM 扩容/缩容
1.新增一个worker节点
cat dm-scale.yaml
worker_servers:
- host: 172.2.1.4
2.执行命令扩容
tiup dm scale-out dm-test dm-scale.yaml -uroot -p
3.回收节点
tiup dm scale-in dm-test -N 172.2.1.4:8262
4.查看dm状态
tiup dm display dm-test
TiDB Binlog 4.0数据同步工具
收集Tidb数据库的binlog日志，提供下游数据库集群的数据同步和准实时备份功能。4.0和之前版本可以使用。5.0有一些不兼容问题，5.0建议使用Ticdc来实现binlog的日志收集。
- pump cluster 连接到上游的tidb clster，tidb内置的 pump client将binlog发送给各个pump。pump用来接收存错binlog日志，pump是分布式的有1个或者多个pump可以水平扩容。可以分布式的接收日志，比如T1T4在第一个pump,T2T5在第二个pump,T3T6在第三个pump上。每个单独的pump会把自己接收到的binlog进行排序，并将排序后的binlog发送给drainer
- 一个drainer只对应一个下游集群，接收drainer日志后，对所有的pump放发送过来binlog进行归并排序后发送到下游数据库。支持relaylog功能，保证下游集群的一致性，可以写到mysql，tidb，kafka或者本地文件中。类似于mysqlbinlog备份binlog。这样在故障可以恢复到任何时刻。有全量备份后+重放binlog可以恢复到任何时间点。
- 使用binlogctl来管理TSO（tidb时间戳），查看pump/drainer的状态/修改状态/暂停下线/异常处理，主要用在出错查看状态，维护集群，异常退出的处理。可以通过grfana监控来查看tidb binlog状态。
- Tidb 2.0版本已经内部集成了tidb binlog
- 上下游数据一定要一致，一般上游备份，下游恢复，然后在开启tidb binlog。因为是同步增量数据的。
- pump单独启用 pump --config pump.toml
- drainer也单独启用 drainer --config drainer.toml -initial-commit-st(为了数据一致性，先获取下游集群的时间戳，用于从哪里开始同步。比如A库10备份，B库恢复，当B库11点开启drainer不加参数就从11点开始，加了就从10点开始。这样不丢失数据。)
相关参数
server_config.tidb.binlog.enable:true # 打开tidb binlog，会影响io
server_config.tidb.binlog.ignor-error:true # 如果有错误，binlog会停止写入。比如主键冲突这种，为了保证数据一致性。
drainer_server_config.syncer.db-type #
drainer_server_config.syncer.to
binlogctl管理工具命令(查看状态/暂停/下线)
#pumps
binlogctl -pd-urls=http://ip:2379 -cmd pumps
binlogctl -pd-urls=http://ip:2379 -cmd pause-pump -node-id ip:port
binlogctl -pd-urls=http://ip:2379 -cmd offline-pump -node-id ip:port
#drainers
binlogctl -pd-urls=http://ip:2379 -cmd drainers
binlogctl -pd-urls=http://ip:2379 -cmd pause-drainers -node-id ip:port
binlogctl -pd-urls=http://ip:2379 -cmd offline-drainers -node-id ip:port
示例：
由TIDB cluster，通过tidb binlog组件写入到mysql中
1.在mysql中创建用户(测试环境给all权限，真实环境看文档给的最小的权限)
create user root@'%' identified by '123456'
grant all on *.* to root@'%';
2.创建tidb binlog部署参数文件
cat tidbbinlog.yaml
pump_servers:
- host: 172.2.1.1
drainer_server:
- host: 172.3.1.1
#定义下游数据库
config:
syncer.db-type:"mysql"
syncer.to.host:"172.4.1.1"
syncer.to.user:"root"
syncer.to.password:"123456"
syncer.to.port:3306
3.在tidb和mysql中创建测试数据(两边都执行)
use test;
create table t(id int primary key,name varchar(20));
insert into t values(1,'TOM')
insert into t values(2,'JACK')
insert into t values(3,'Frank')
4.使用tiup对tidb进行扩容，增加pump和drainer节点
tiup cluster scale-out clustername tidbbinlog.yaml -uroot -p
tiup cluster display clustername #查看是否部署成功
5.启动pump和drainer节点，然后在开启tidb的binlog日志。(binlog日志默认是不开启的)
tiup cluter edit-config clustername
在global下边增加
server_configs:
tidb:
binlog.enable:true
binlog.ignore-error:true
重新载入使参数生效。滚动重启
tiup cluster reload clustername
登录tidb 查看节点是否正常,默认不配置从哪个点开始。则默认是当前时间点。
show pump status
show drainer status
5.登录tidb数据库
新增一行数据库
use test;
inser into t select 4,'Tony';
登录下游数据库，验证数据
use test;
select * from t;
6.管理Tidb binlog
安装binlogctl
wget https://download.pingcap.org/tidb-v5.0.0-linux-amd64.tar.gz
tar -xf tidb-v5.0.0-linux-amd64.tar.gz
在bin目录下。可以找到命令行
#pumps
binlogctl -pd-urls=http://ip:2379 -cmd pumps
binlogctl -pd-urls=http://ip:2379 -cmd pause-pump -node-id ip:port
binlogctl -pd-urls=http://ip:2379 -cmd offline-pump -node-id ip:port
#drainers
binlogctl -pd-urls=http://ip:2379 -cmd drainers
binlogctl -pd-urls=http://ip:2379 -cmd pause-drainers -node-id ip:port
binlogctl -pd-urls=http://ip:2379 -cmd offline-drainers -node-id ip:port
重启drainers
进入到已经部署的drainer的节点
cd /tidb-deploy/drainer-8249/bin/
drainer -pd-urls=ip:port -config ../conf/drainer.toml
缩容Tidb binlog
首先关闭binlog
tiup cluter edit-config clustername
在global下修改
server_configs:
tidb:
binlog.enable:false
binlog.ignore-error:false
重新载入使参数生效。滚动重启
tiup cluster reload clustername
缩容drainer
tiup cluster scale-in clustername --node ip:port
缩容pump
tiup cluster scale-in clustername --node ip:port
需要执行清理缓存
tiup cluster prune clustername
Tidb的binlog格式 与mysql binlog row格式类似，以行数据变更为做小的记录单位，只有提交的事务才会被记录，记录的是完整的事务，会记录主键和开始的时间戳，会记录提交的时间戳。
TiCDC 5.0数据同步工具
tidb binlog是从tidb sever的获取的dml日志，叫binlog日志。 ticdc 直接抽取存储层tikv的变更日志，实现tidb增量数据(产生的日志)的同步。数据可以还原到上游集群任意时刻的状态。开发数据协议也支持其他系统订阅数据变更。具有高可用性，高性能，支持丰富下游数据格式的功能。
- Tidb server接收sql并调用Tikv cluter
- Tikv cluster只输出自己数据改变的日志，并传送到Ticdc cluster
- Ticdc cluster通过capture,逻辑拼装日志，提供输出日志的接口，发送数据。
- 通过开放协议 将数据传输到下游。
- 每个capture会拉取一部分数据，每一个capture是不一样的。通过协同选择一个owner将数据排序发送。
- 适用于上游是tidb，(异步复制场景)下游是mysql兼容的任何数据和kafka，为监控/缓存/全文索引/分析引擎/异构数据主从复制提供数据源。
- 推荐配置16c,64g,ssd,万兆网卡2块，最少2个ticdc，redhat/centos 7.3
- ticdc由 cdc cil管理，通过cdc binary 执行cil命令。
- 限制1：Ticdc同步的表至少需要有一个有效的索引，主键/可视为唯一索引(表结构定义每一列都非空/不存在虚拟列)
- 限制2：不支持单独使用Rawkv的Tikv集群/4.0创建sequence的ddl操作和sequence函数/Tikv hibernate region
- 限制3：会有兼容问题
- 限制4：5.0版本操作4.0集群会有不兼容问题。
- 使用tiup部署后，grafana已经集成了ticdc的监控。
部署：
1.在建立tidb cluster之前，如果有这个需求，直接在部署文件中加入参数即可。
tiup cluster deploy clustername v5.0.0 ./topology.yaml
cat topology.yaml
cdc_servers:
- host:ip1
gc-ttl:86400
- host:ip2
2.扩容方式
tiup cluster scale-out clustername scale-out.yaml
cat scale-out.yaml
cdc_servers:
- host:ip
port:8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"
3.创建同步任务
tiup cdc cil changefeed create
--pd=http://ip:port
--sink-url="mysql://root@ip:port"
-changefeed-id="simple-replication-task"
changefeed 一个同步任务叫一个changfeed
sink-url 下游数据库地址，目前支持mysql/tidb/kafka/pulsar
changefeed-id 任务名称，不指定会生成一个uuid。
--start-ts 从那个时间点开始读取。不写默认当前时间。
--target-ts 读取到那个时间点，不写一直复制。
下游如果是mysql/tidb
worker-count: 向下游执行sql的并发执行，可选默认是16.
max-txn-row: 向下游执行sql的batch大小，可选默认是256
下游如果是kafak
protocol:输出到kafka的消息协议。可选default/canal/avro/maxwell.
max-message-bytes: 每次向kafka broker发送消息的最大数据量，可选默认是64MB
4.查询所有ticdc同步任务
tiup cdc cil changefeed list #全部任务
tiup cdc cil changefeed list --pd=http://ip:port #单个任务
tiup cdc cil changefeed query -s --pd=http://ip:port --changefeed-id=任务名称 #指定详细任务
normal比较常见
stop是出错了
finished是完成
5.停止/恢复/删除任务
tiup cdc cil changefeed pause -s --pd=http://ip:port --changefeed-id=任务名称
tiup cdc cil changefeed resume -s --pd=http://ip:port --changefeed-id=任务名称
tiup cdc cil changefeed reomve -s --pd=http://ip:port --changefeed-id=任务名称
6.更新Ticdc同步任务
Ticdc从4.0.4开始支持非动态修改同步任务配置，先暂停-修改-恢复的流程
暂停任务
tiup cdc cil changefeed pause -c 任务名称 --pd=http://ip:port
更新任务
tiup cdc cil changefeed update -c 任务名称 --pd=http://ip:port --sink-url="mysql://root:ip:port/?max-txn-row=20&worker-number=8" --config=changefeed.toml
恢复任务
tiup cdc cil changefeed resume -c 任务名称 --pd=http://ip:port
7.示例：
pd:172.1.1.1:2379
tikv:172.2.1.1/172.2.1.2/172.2.1.3:20160
ticdc cluster: 17.3.1.1:8300
mysql:172.4.1.1:3306
tidb cluster:tidb-test
查看tidb cluster状态
tiup cluster display tidb-test
扩容方式增加ticdc节点
cat scale-out.yaml
cdc_servers:
- host:172.3.1.1
port:8300
deploy_dir: "/tidb-deploy/cdc-8300"
log_dir: "/tidb-deploy/cdc-8300/log"
执行扩容命令
tiup cluster scale-out tidb-test scale-out.yaml -uroot -p
安装ctl工具
tiup ctl:v5.0.0 cdc capture list --pd=http://172.1.1.1:2379
对下游mysql进行操作
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -uroot -p123456
创建库和表
create database test;
create table t(id int primary key,name varchar(20));
不插入数据
增加同步任务
tiup cdc cil changefeed create
--pd=http://172.1.1.1:2379
--sink-url="mysql://172.4.1.1:3306"
-changefeed-id="mysql-frist-task" --sort-engine="unified"
创建完成后，会自动连接下游数据，如果出错是创建不成功的
查询任务
tiup cdc cil changefeed list --pd=http://172.1.1.1:2379
查看详细的任务信息
tiup cdc cil changefeed query -s --pd=http://172.1.1.1:2379 --changefeed-id=mysql-frist-task
tidb插入数据
use test;
insert into t select 1,'Tom';
查看下游mysql是否有数据
use test;
select * from t;
缩容Ticdc
暂停任务
tiup cdc cil changefeed pause --pd=http://172.1.1.1:2379 --changefeed-id=mysql-frist-task
删除任务
tiup cdc cil changefeed remove --pd=http://172.1.1.1:2379 --changefeed-id=mysql-frist-task
缩容ticdc
tiup cluster scale-in tidb-test --node 172.3.1.1:8300
2022年5月17日 第八天
TiDB server主要作用:
- 处理客户端的连接，包含用户密码的验证
- SQL语句的解析和编译生成物理执行计划
- 关系型数据库与KV的转化
- SQL语句的执行
- 在线DDL语句的执行
- 垃圾回收
- protocol layer/parse/compile 通过协议提供服务接收sql语句，通过解析和优化生成执行计划。
- executor/distsql 负责分批的执行sql的执行计划。
- transaction/kv 负责执行事务相关的执行计划，比如写如操作。
- pd client/tikv client 负责与pd(获得时间戳)和tikv(获得数据)进行交互。
- schemaload/worker/startjob 负责DDL的执行，执行的时候不阻塞tidb通过这三个模块来实现的。
- membuffer 用于读取缓存出的数据和元数据，以及登录认证的信息和统计信息。
- gc 负责垃圾回收
- parse 通过lex词法分析，将关键字解析成token。 通过yacc语法分析。生成ast树形结构，后期compile通过树形结构来优化。
-
compile 接收到了ast树后，首先合法性验证，看表是否在库中是存在的。然后通过一些规则座逻辑优化(比如转化连接为子查询等等)，逻辑优化后在物理优化，通过考虑数据分布和大小也就是结合统计信息是走索引还是全表扫描记性物理优化，生成了执行计划。
-
mysql表数据转为tidb的kv(其中一种方式) mysql id name phone birthday 1 aa 123123 90/01/01 2 bb 456345 91/01/01 tidb KEY VALUES t1_r1 aa,123123,90/01/01 t1_r2 bb,456345,91/01/01 键值对是存储在region里，默认大小是96M，达到144M会分裂为两个region来存储，不同region可以存储在不同的tikv中。
-
SQL读写模块的协作
执行计划生成后，交给executor来通过执行计划执行，每一层调用模块协作获得结果。 对于复杂查询，比如表连接，嵌套循环，范围扫描等等使用DistSQL模块来执行，通过转变为单表任务来发送给tikv。 对于简单查询，比如通过索引，等值查询使用KV模块来执行。 对于事务相关，比如写操作等，使用Transaction组件，然后KV组件来执行。在事务提交的时候transaction通过pd clint和pd来获取事务提交的一个时间戳。 无论是那种都通过tikv client把请求发送给tikv cluster来处理。
-
在线DDL相关模块
Tidb server 通过workers进行在线ddl操作。虽然有多个tidbserver都可以接受ddl操作，但在同一时间内只有一个DDL会执行。 用户发送ddl语句，通过start job接收，接收后变为一个job送入到TiKV中的job queue中排队。同一时间只有一个tidb server也就是owner(每一个owner有一个时间段到期后重新选举，owner并不是一直在一个tidbserver上)。owner的workers模块取TiKV中的job queue的第一个job执行。即使这个job是其他tidb server发送到job queue中的。但是只有当前owner来执行。job执行完成后存放在history queue中，然后owner再去执行第二个job。 schemaload。当tidbserver选举成为owner之后，会将最新的表和schema信息同步到内部的缓存中。根据内部的信息 然后去执行job queue。 job存放在tikv持久化，是防止tidb server宕机。虽然宕机了但是ddl语句还是存在tikv中的是持久化存储的。
-
GC垃圾回收机制 清理的是用于MVCC机制的历史数据。每一个TiDB Server都有一个GC模块。在一个时间段内有一个GC leader。 GC每10分钟触发一次，默认是safe point时间之前数据会被回收。 GC LIFE TIME默认是10分钟之内。 首先找到旧信息，对于那些表已经drop掉，索引已经删除掉的优先清理，然后再去清理delete这样的数据。
-
TiDB Server 缓存 默认使用整个TiDB数据库的全部内存，用于sql结果(join等，事务修改的结果都先放缓存中)，线程缓存(每个模块，一个模块是一个线程)，元数据/统计信息(编译时候使用的信息，用户的密码)
通过2个主要参数来管理 tidb_mem_quota_query 每一条sql语句默认占用的缓存大小。 oom-action 当sql执行超过了上边参数的大小后，由这个参数来决定是终止返回报错还是记录日志。
PD Cluster:
- TiKV的元数据存储
- 分配全局ID和事务ID
- 生成全局时间戳TSI
- 收集集群信息并调度
- 提供TiDB Dashboard服务
TiKV Cluster：给予lsm tree的结构基于raft和rocksdb来实现。
- 数据的持久化
- 分布式事务支持
- 副本强一致与高可用
- MVCC
- Coprocessor算子下推
TiFlash:
- 列式存储提高查询分析效率
- 支持强一致性和实时性
- 业务隔离
- 智能选择
