备份的重要性
- 数据库恢复
- 审计和分析
- 典型DBA任务
备份的类型
- 热备,允许应用程序完全访问数据。
- 冷备,不允许应用程序访问年数据
- 温备,允许应用程序读取,但不能修改
热备份
- 热备份是在读取和修改数据时进行的,几乎不会中断您与数据交互或操作数据的能力。
- 对于读取和修改数据的操作,系统仍可访问。
- 通过以下方式锁定数据:
- 使用MVCC
- 锁定在较低级别
- 完全不锁定,以便应用程序可以继续访问数据
冷备份
- 当用户无法访问数据时发生。
- 防止对数据执行任何活动
温备份
- 在访问数据时发生
- 具有不必完全锁定最终用户的优势
- 可能会导致性能问题,因为备份期间无法修改数据。
备份技术
- 逻辑备份
- 文本形式:SQL语句
- 物理备份
- TiDB数据库文件的二进制副本
- 基于复制
- 增量备份
- 通过同步复制创建
逻辑备份
通过使用Dumpling 或 Lightning 执行完整的数据转储。
这些数据转储基于特定的时间点,但是在所有备份技术中是较慢的。
优势: 该过程将创建一个SQL脚本,可以在TiDB服务器上执行该脚本。
劣势: 转储过程中,锁定表会阻止用户在备份过程中修改数据。
物理备份
- 通过复制数据文件创建
- 必须还原到相同的存储引擎和TiDB版本
- 可以跨机器架构还原
- 比逻辑备份和恢复执行和还原速度更快
物理备份的文件
- 原始二进制备份比逻辑备份块,该过程是简单的文件或文件系统副本
- 这些副本跟TiDB数据库本身在磁盘上存储的格式大小完全相同的格式保存数据库
物理备份的条件
- 备份期间,服务器不得修改数据文件
- 如果要复制实时数据文件,则防止写入这些文件
备份恢复技术对比
方法 | 冷/热/温备 | 逻辑备份/物理备份 | 一致性 |
---|---|---|---|
BR工具 | 热备 | 物理 | 是 |
Dumpling | 热/温备 | 逻辑 | 是 |
复制 | 热备 | 逻辑 | 是 |
操作系统拷贝 | 冷/温 | 物理 | 是 |
备份恢复技术的选择
使用备份恢复工具BR进行备份恢复
BR介绍
BR全称为Backup & Restore,是TiDB分布式备份恢复的命令行工具,用于对TiDB集群进行数据备份和恢复
适用场景
- 大数据量
- 速度较快
- SST文件
- 只能恢复到TiDB数据库
BR原理
在一次备份或恢复中,各个TiKV节点都会有一个对应的备份路径,TiKV备份时产生的备份文件会保存在该路径下,恢复时也会从该路径读取相应的备份文件,每个节点的leader 数据会备份到每个节点的备份目录。
BR的使用限制
1、BR恢复到TiCDC/Drainer的上游集群时,恢复数据无法由TiCDC/Drainer同步到下游
2、备份集群和恢复集群采用相同的排序规则(new_collations_enabled_on_first_bootstrap)
3、版本兼容性(使用-check-requirements=false 强行跳过版本检查)
4、某些功能在开启或关闭状态下,会导致KV格式发生变化
BR命令
- 通过SQL语句
TiDB支持使用SQL语句backup和restore 进行备份恢复。如果要查看备份恢复的进度,可以使用show backups|restores语句。 - 通过命令行工具
TiDB支持使用BR命令行工具进行备份恢复。
全库备份
br backup full --pd "${PD_IP}:${PD_PORT}" --storage "local:///tmp/backup" --ratelimit 120 --log-file backupfull.log
–storage: 每个节点leader备份的位置,另外在做恢复的时候,一定要包含所有sst,不仅仅只包含自己的。所以这个应该用共享存储。
ratelimit: 速度上限 120M/s
全库恢复
br restore full --pd "${PD_IP}:${PD_PORT}" --storage "local:///tmp/backup" --ratelimit 128 --log-file restorefull.log
单库备份
br backup db --pd "${PD_IP}:${PD_PORT}" --db test --storage "local:///tmp/backup" --ratelimit 120 --log-file backupdb.log
单库恢复
br restore db --pd "${PD_IP}:${PD_PORT}" --db "test" --storage "local:///tmp/backup" --log-file backupdb.log
单表备份
br backup table --pd "${PD_IP}:${PD_PORT}" --db test --table utable --storage "local:///tmp/backup" --ratelimit 120 --log-file backuptable.log
单表恢复
br restore table --pd "${PD_IP}:${PD_PORT}" --db test --table utable --storage "local:///tmp/backup" --ratelimit 120 --log-file restoretable.log
过滤恢复数据
可以使用--filter 或者-f指定使用表库过滤
br restore full --pd "${PD_IP}:${PD_PORT}" --filter 'db*.tbl*' --storage "local:///tmp/backup" --ratelimit 120 restorefilter.log
增量备份
增量备份,只需要在备份的时候指定上一次的备份时间戳 --lastbackupts即可
br backup full --pd "${PD_IP}:${PD_PORT}" -s "local:///tmp/increment" --lastbackupts ${LAST_BACKUP_TS}
LAST_BACKUP_TS = `br validate decode --field = "end-version" -s "local:///tmp/backup" | tail -n1`
增量恢复
增量恢复的方法和使用BR进行全量恢复的方法并没有差别。需要注意的是:恢复增量数据的时候,需要保证备份时指定的last_backup_ts之前的备份数据已经全部恢复到目标集群。
最佳实践
- 推荐在业务低峰时执行备份操作
- 恢复期间对在线业务影响很大,建议低峰期或者限速(rate-limit)进行恢复
- 备份和恢复最好都只使用串行
- 指定存储的时候,指定共享存储
实验-安装工具
[root@tiup ~]# wget https://download.pingcap.org/tidb-toolkit-v5.0.1-linux-amd64.tar.gz
[root@tiup ~]# tar xvf tidb-toolkit-v5.0.1-linux-amd64.tar.gz
tidb-toolkit-v5.0.1-linux-amd64/
tidb-toolkit-v5.0.1-linux-amd64/bin/
tidb-toolkit-v5.0.1-linux-amd64/bin/tikv-importer
tidb-toolkit-v5.0.1-linux-amd64/bin/dumpling
tidb-toolkit-v5.0.1-linux-amd64/bin/br
tidb-toolkit-v5.0.1-linux-amd64/bin/tidb-lightning
tidb-toolkit-v5.0.1-linux-amd64/bin/mydumper
tidb-toolkit-v5.0.1-linux-amd64/bin/tidb-lightning-ctl
tidb-toolkit-v5.0.1-linux-amd64/bin/pd-tso-bench
tidb-toolkit-v5.0.1-linux-amd64/bin/sync_diff_inspector
加入到换进变量中
[root@tiup ~]# grep -i 'PATH' ~/.bash_profile
PATH=$PATH:$HOME/bin
export PATH
export PATH=/root/.tiup/bin:$PATH:/root/tidb-toolkit/bin
实验-全库备份
1、 添加备份目录
在所有的TiKV节点创建文件夹/tmp/backup,用来存储节点的备份文件。
[root@tiup ~]# mkdir /tmp/backup
循环在每一个TiKV节点上进行操作。
2、全库备份
连接到其中一个PD节点,开始进行数据库全备份:
[root@tiup tidb-toolkit]# ./br backup full --pd "192.168.16.10:2379" --storage "local:///tmp/backup" --ratelimit 120 --log-file backupfull.log
Detail BR log in backupfull.log
Full Backup <----------------------------------------------------------------------------------> 100.00%
Checksum <-------------------------------------------------------------------------------------> 100.00%
[2023/06/27 17:22:29.449 -04:00] [INFO] [collector.go:67] ["Full Backup success summary"] [total-ranges=12] [ranges-succeed=12] [ranges-failed=0] [backup-checksum=55.745741ms] [backup-fast-checksum=11.735203ms] [backup-total-regions=66] [backup-total-ranges=66] [total-take=820.332664ms] [BackupTS=442473106335596546] [total-kv=1054] [total-kv-size=77.76kB] [average-speed=94.79kB/s] [backup-data-size(after-compressed)=46kB] [Size=45997]
--pd : 连接TiDB数据库的PD节点,最好在PD节点上执行,即连接本节点
--storage: 备份文件存储在TiKV节点上的位置
--ratelimit : 对于备份所用存储带宽限速
--logfile : 备份日志文件
3、查看备份目录
备份结束后,可以到各个TiKV节点检查备份文件
[root@tiup backup]# cd 1
[root@tiup 1]# ls
16_8_355f0b5a4a8313c61daccaf1f055ac6ce3e0abaeb3d9fda7eb60557014f38dac_1687900949109_write.sst
16_8_495c5d2e3a1901df43133318e03236d08d1c8882cdd7b452579a4fcd82ccb718_1687900949092_write.sst
18_9_36adb8cedcd7af34708edff520499e712e2cfdcb202f5707dc9305a031d55a98_1687900949120_write.sst
18_9_c2baa1d0dee98e26766aa462a873c405eaad66653a52db6bc9e1d584f6aebcc7_1687900949127_write.sst
24_12_afb978bcbf32cf0ba18923daa88bdab19c00ad22f4fe49863f102827eb831e21_1687900949153_write.sst
24_12_d0a5865efa1d90636cf0c26e991e1f13ad4ef35c631530b967aa1e342d73208b_1687900949147_write.sst
38_19_2d2f68c250f77d93ffb8ea543a425eebeea7c92d1f033e9d32cdb914ca4341a9_1687900949224_write.sst
38_19_8dd75043152f9a7a07ef9bc0b24b629d464621806e3c93219cac918ec3d5b346_1687900949217_write.sst
38_19_a24c493bf7e801abe1238806dd31796f911e7dd0970118b9315f0a7366532873_1687900949229_write.sst
42_21_ff781abda573afc7d7878f20390a290dcdb471bf12a8cbabf359ccf9e8d37084_1687900949247_write.sst
6_3_302753bc98ec93e98edea12aeac15074da779bb66c735c8ce184eacf43f1e7c2_1687900949297_write.sst
6_3_c11c7f8053ba1d8a3efe53decec79ee83321252578aaa0e09024538869d60d0d_1687900949290_write.sst
4、查看执行备份的节点
同时在执行备份的节点上,也会自动创建文件/tmp/backup 用来存储元数据和锁信息
cd /tmp/backup/
[root@tiup backup]# ls
backup.lock backupmeta
5、进行单库备份
mkdir /tmp/test
[root@tiup tidb-toolkit]# ./br backup db --pd "192.168.16.10:2379" --db test --storage "local:///tmp/test" --ratelimit 120 --log-file backupfull.log
实验-恢复演示
1、故障模拟
[root@tiup ~]# mysql -uroot -p -P4000 -h192.168.16.10
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 405
Server version: 5.7.25-TiDB-v6.1.6 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible
mysql> drop database test;
Query OK, 0 rows affected (0.22 sec)
2、备份汇总
接下来准备进行恢复,首先将所有TiKV目录/tmp/test下面都备份文件拷贝到其他节点.并且保证在所有的TiKV节点上都有完整的备份。
cd /tmp/test
scp tikv2:/tmp/test/* .
scp tikv3:/tmp/test/* .
循环操作,更换不同节点,保证所有tikv节点上都有完整备份
3、开始进行恢复
[root@tiup tidb-toolkit]# ./br restore db --pd "192.168.16.10:2379" --db "test" --storage "local:///tmp/test" --log-file restoredb.log
Detail BR log in restoredb.log
DataBase Restore <----------------------------------------------------------------------> 100.00%
[2023/06/27 22:32:24.843 -04:00] [INFO] [collector.go:67] ["DataBase Restore success summary"] [total-ranges=2] [ranges-succeed=2] [ranges-failed=0] [split-region=436.944µs] [restore-ranges=1] [total-take=2.004639305s] [Size=1560] [BackupTS=442477980702998563] [total-kv=2] [total-kv-size=58B] [average-speed=28.93B/s] [restore-data-size(after-compressed)=1.56kB]
4、验证
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA |
| PERFORMANCE_SCHEMA |
| mysql |
| test |
+--------------------+
5 rows in set (0.01 sec)
实验-单表备份和恢复
1、创建备份目录
在所有TiKV节点创建文件夹/tmp/t1,用来存储本节点的备份文件
mkdir -p /tmp/t1
循环在每一个TiKV节点上进行操作
2、备份表
[root@tiup tidb-toolkit]# ./br backup table --pd "192.168.16.10:2379" --db "test" --table t1 --storage "local:///tmp/t1" --log-file backupt1.log
Detail BR log in backupt1.log
Table Backup <--------------------------------------------------------------------------> 100.00%
Checksum <------------------------------------------------------------------------------> 100.00%
[2023/06/27 22:40:38.475 -04:00] [INFO] [collector.go:67] ["Table Backup success summary"] [total-ranges=1] [ranges-succeed=1] [ranges-failed=0] [backup-checksum=3.698861ms] [backup-fast-checksum=429.128µs] [backup-total-ranges=1] [backup-total-regions=1] [total-take=236.714686ms] [BackupTS=442478110541348866] [total-kv=2] [total-kv-size=58B] [average-speed=245B/s] [backup-data-size(after-compressed)=1.56kB] [Size=1560]
3、模拟故障
mysql> use test;
mysql> drop table t1;
4、备份汇总
接下来准备进行恢复,首先将所有TiKV目录/tmp/t1下面都备份文件拷贝到其他节点.并且保证在所有的TiKV节点上都有完整的备份。
cd /tmp/t1
scp tikv2:/tmp/t1/* .
scp tikv3:/tmp/t1/* .
循环操作,更换不同节点,保证所有tikv节点上都有完整备份
5、开始恢复
[root@tiup tidb-toolkit]# ./br restore table --pd "192.168.16.10:2379" --db "test" --table t1 --storage "local:///tmp/t1" --log-file restoret1.log
Detail BR log in restoret1.log
Table Restore <-------------------------------------------------------------------------> 100.00%
[2023/06/27 22:46:26.773 -04:00] [INFO] [collector.go:67] ["Table Restore success summary"] [total-ranges=2] [ranges-succeed=2] [ranges-failed=0] [split-region=499.422µs] [restore-ranges=1] [total-take=1.062222347s] [Size=1560] [BackupTS=442478201636388866] [total-kv=2] [total-kv-size=58B] [average-speed=54.6B/s] [restore-data-size(after-compressed)=1.56kB]
6、验证
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1 |
+----------------+
1 row in set (0.00 sec)