019、数据库管理之备份恢复管理(BR)

企业开发 2023-07-11 17:32:36 阅读次数: 0

备份的重要性

  • 数据库恢复
  • 审计和分析
  • 典型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)

猜你喜欢

转载自blog.csdn.net/wangzhicheng987/article/details/131045760
今日推荐
基于大语言模型的开源知识库问答系统 MaxKB GitHub Star 数量突破 5,000 个！
美国拟限制 AI 大模型出口中国和俄罗斯
苹果将与 OpenAI 达成协议，将 ChatGPT 应用于 iPhone
openKylin 社区生态委员会第六次会议圆满召开
阿里云正式发布通义千问 2.5
Python 3.13 发布首个 Beta：实验性自由线程模式和 JIT、改进交互式解释器
Stack Overflow 拿我的代码去训练 AI 大模型，还封了我的账号
Pop!_OS 的 COSMIC 桌面完成 App Store 上架工作
《2024 年一季度互联网投融资运行情况》研究报告
报告：Django 仍然是 74% 开发者的首选
15 年前上了“FFmpeg 耻辱柱”，今天他还得谢谢咱——腾讯QQPlayer一雪前耻？
TIOBE 5 月榜单：Fortran “复活”进入 Top 10
周排行
记一下去大梅沙的准备（2018-05-26）
Spring 注解 事务
基于HTTP协议的客户端缓存
阿里云rds 备份和还原
[PHP] 几个拖慢 PHP 程序/API 运行速度的点
python 代码风格------------PEP8规则
js控制json生成菜单——自制菜单（一）
将字符串: 'k:1|k1:2|k2:3|k3:4 ' ,处理成 python 字典: {'k':1, 'k1':2, ...}
微信小程序转支付宝小程序
Qt551.窗口滚动条
每日归档
更多
2024-05-13(18)
2024-05-12(0)
2024-05-11(38)
2024-05-10(38)
2024-05-09(35)
2024-05-08(42)
2024-05-07(14)
2024-05-06(40)
2024-05-05(0)
2024-05-04(7)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022