前文
如果把数据库的工作建设分为三大体系，从前中后的角度来看，笼统一点可以分为开发设计体系【前】、监控优化体系【中】、备份恢复体系【后 】，类似规划设计、运营管理、安全保障的关系，构成数据库整个生命周期的管理。
三大体系中可以看出一个产品的覆盖度广窄 ， 三大体系可以洞悉一个产品的成熟度深浅。三大体系简单简述如下。
- 开发设计体系考虑的更多是产品技术造型、基准测试报告、最佳施工应用实践、开发者使用标准规范等设计因素。让产品对准业务有的放矢。
- 监控优化体系考虑更多是流量、延迟、饱和度、关键指标、查询优化等运维因素，让产品健康正常的在生活环境中运行。
- 备份容灾体系考虑的高可用、业务连续性、不可抵抗力的灾后建设。 必要通过额外的技术手段，保障产品的售后安全
对业务和DBA而言，开发设计体系和监控优化体系是DBA经常要做的事情，而 备份容灾体系则是一劳永逸的工作，初次进行全面的数据备份策略要花较大的精力。
MySQL的备份容灾体系成熟度已经很高，针对MySQL的备份容灾和TiDB的备份容灾做了技术对比。
MySQL备份体系
MySQL的备份技术栈有mysqldumper、mydumper等逻辑备份工具，也有xtabackup等物理备份工具 。
逻辑备份的定义，从数据库的接口层出发，数据库客户端访问数据库服务端，像其它SQL语句一样进行正常的解析，最后输出结果为SQL语句或者CSV文件。
物理备份区别于逻辑文件，直接针对硬盘存在的持久化的物理文件进行备份，因为不需要SQL解析，所以处理速度会很快。
mysqldumper是MySQL典型的逻辑备份工具，可以指定某个库、某个表、甚至全库进行备份，当进行备份操作的时候，打开Gerneral日志，mysqldumper会启用全局锁，flush table with read lock 会阻止其它表和数据进行DDL和DML操作，必须备份完成才会解锁。
mysqldumper这样的目的是为了备份一致性。数据库工作生产时，一边在大量写入数据，一边需要对数据进行备份，备份的数据要接近生产数据的真实状态，这个就是备份一致性的作用。MySQL为了做到这一点，提供全局锁flush table with read lock
mydumper相对于mysqldumper，它的备份速度要快的多， 因为mysqldumper是单线程，而mydumper是多线程备份，mydumper在满足mysqldumper的基本功能上，还提供对目标文件进行压缩编码。
mydumper同样存在不足，它比mysqldumper需要占用更多的资源，而且数据进行恢复的时候，同样是在MySQL的逻辑层进行SQL解析，这个需要花费大量的时间。进行数据恢复的时候mydumper比mysqldumper占不了多少优势。
xtabackup是针对innodb引擎的备份工具，目前有2.4和8.0版本，其中xtabackup2.4是针对MySQL5.6和MySQL5.7，而xtabackup8.0针对的是MySQL8.0。
xtabackup的备份技术原理分为三步走。
- 第一步，物理备份开始，针对MySQL最近一次checkpoint点进行redo日志的日志备份。
- 第二步 ，针对IBD文件【公共表空间文件和独立表空间、undo文件】、非IBD文件【上全局锁】、进行备份。
- 第三步，当最后一个非IBD文件传输完成 ，代表redo日志拷贝结束，整个物理备份结束。
xtabackup的每一步都为了备份一致性
- 第一步的作用 识别并获取目标数据源，对那些刚刷到硬盘上，没有来得及进入innodb引擎的数据进行回放，对一些表空间的脏页尚未递交成功，马上放弃通过redo日志进行回放。
- 第二步的作用 拷贝物理文件，针对非IBD文件进行全局锁，防止这个时候有人对非IBD进行DML和DDL操作。在8.0.27版本，只允许进行DDL操作，不允许进行DML操作，进一步细化备份一致性的粒度。
- 第三步的作用 非IBD文件传输完成结束，自行进行解锁，同行监控REDO的线程也结束，备份到了最后阶段。
关于增量备份，基于初次全量备份后，xtabackup通过识别REDO日志的LSN是否发现变化 ，LSN的序列号是往前递进的，是否变化一目了然，增量备份只叠加备份后的数据。
关于数据恢复，可以基于全量备份恢复或者增量恢复，或者基于全量备份恢复+ 日志备份恢复的方式。
物理备份上，xtabackup使用了全局锁技术，REDO日志监控技术，非IBD文件传输等同于REDO监控结束等方法保障了全量备份、增量备份，实现了基于时间点的数据恢复，恢复到指定的数据恢复点上。
TiDB备份体系
TiDB支持mysqldumper和mydumper工具， 但是只能逻辑层面对已经持久化的数据进行备份，无法进行一致性备份。
mysqldump使用--single-transaction进行一致性备份
root@henley-Inspiron-7447:/tmp# mysqldump -h192.168.10.14 -u root -pGmcc@1234 -P4000 --single-transaction --databases sysbench >sysbench2.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: Couldn't execute 'ROLLBACK TO SAVEPOINT sp': SAVEPOINT sp does not exist (1305)
mydumper使用备份的时候，提示更是明确
** (mydumper:6185): CRITICAL **: 16:34:20.943: Couldn't acquire global lock, snapshots will not be consistent: FLUSH TABLES WITH READ LOCK is not supported. Please use @@tidb_snapshot
究底根因，目前TiDB没有支持全局锁,只支持tidb_snapshot，那么tidb_snapshot是什么？
tidb> FLUSH TABLES WITH READ LOCK;
ERROR 1105 (HY000): FLUSH TABLES WITH READ LOCK is not supported. Please use @@tidb_snapshot
这个要说到TiDB的内存管理机制，对于写进来的数据，TiDB把增量数据放到内存，提交成功的数据放在基线数据里面，内存的数据待到适当时机，会冻结合并到基线数据里面。
基线数据是持久化刷新到硬盘里面的数据，每一行数据都会对应一个唯一的时间戳
TiDB的物理备份工具BR的技术原理，就是把已经提交后的物理文件进行时间戳的扫描，把对应的时间点的数据文件信息都集中在一起，分为三步走。
- 第一步扫描KEY VALUE，从TIKV所在的Region读取备份时间点对应的数据。
- 第二步生成SST，将数据保存到SST文件中，这些文件存储在内存中。
- 第三步上传SST，将SST文件上传到存储路径。
下面做个小测试，三个时间点2024-04-15 10:18:32, 2024-04-15 10:18:35,2024-04-15 10:22:32,其中第一个时间连续 备份三次， 期间数据一直在不停的增加中。
tiup br backup full --pd "192.168.153.128:2379" --backupts '2024-04-15 10:18:32' --storage "/tidb/backup/1
tiup br backup full --pd "192.168.153.128:2379" --backupts '2024-04-15 10:18:32' --storage "/tidb/backup/2
tiup br backup full --pd "192.168.153.128:2379" --backupts '2024-04-15 10:18:32' --storage "/tidb/backup/3
tiup br backup full --pd "192.168.153.128:2379" --backupts '2024-04-15 10:18:35' --storage "/tidb/backup/4
tiup br backup full --pd "192.168.153.128:2379" --backupts '2024-04-15 10:22:32' --storage "/tidb/backup/5
在TiDB的不断的增加数据的过程中，第1个时间点三次备份都是122M，第2个时间点是比第1个时间点多3秒，备份后数据是138M，第3个时间点备份是174M，时间越往前，识别的数据就越多。
而且TiDB的物理备份的过程中，只从后端爬物理文件，不需要与其它模块协同。而MySQL会加上全局锁，防止前端写入数据。两者比较相对而言，MySQL的备份机制显得谨慎一点，延迟一点，多些安全。
快照的好处在于记住某个时间点的数据总集，可以进行某个时间点的数据恢复，例如误操作把表truncate了，由于表以前做过快照，我依然可以通过相同的时间点把数据物理备出来。
// 对大表进行truncate
mysql> truncate table 表名3;
Query OK, 0 rows affected (55.24 sec)
mysql>
mysql> truncate table 表名2;
Query OK, 0 rows affected (0.11 sec)
mysql> truncate table 表名1;
Query OK, 0 rows affected (0.13 sec)
// truncate后已经是28分的事，按照 11:26:30去备份依然有数据,备分到2文件夹上面
root@server128 tidb]# tiup br backup full --pd "192.168.153.128:2379" --backupts '2024-04-15 11:26:30' --storage "/tidb/backup/2"
Starting component br: /root/.tiup/components/br/v8.0.0/br backup full --pd 192.168.153.128:2379 --backupts 2024-04-15 11:26:30 --storage /tidb/backup/2
Detail BR log in /tmp/br.log.2024-04-15T11.28.38+0800
Full Backup <-------------------------------------------------------------------------------------------------> 100.00%
Checksum <----------------------------------------------------------------------------------------------------> 100.00%
[2024/04/15 11:28:48.091 +08:00] [INFO] [collector.go:77] ["Full Backup success summary"] [total-ranges=47] [ranges-succeed=47] [ranges-failed=0] [backup-fast-checksum=50.434786ms] [backup-checksum=1.188532642s] [backup-total-ranges=122] [total-take=9.641031363s] [BackupTS=449092410408960000] [total-kv=1153773] [total-kv-size=247.6MB] [average-speed=25.68MB/s] [backup-data-size(after-compressed)=112MB] [Size=112044657]
除了内置的快照，TiDB也支持外置的快照 ，通过LVM也可以对数据进行备份。
如果使用LVM进行备份，注意安装的时候，需要把TiDB的数据盘安装在LVM的 逻辑卷上面，以下TiDB的数据盘安装在 /dev/mapper/centos_server153-tidb--data下面。
[tidb@server128 backup]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos_server153-root 173G 104G 63G 63% /
devtmpfs 6.3G 0 6.3G 0% /dev
tmpfs 6.3G 0 6.3G 0% /dev/shm
tmpfs 6.3G 75M 6.2G 2% /run
tmpfs 6.3G 0 6.3G 0% /sys/fs/cgroup
/dev/sda1 269M 117M 135M 47% /boot
/dev/mapper/centos_server153-tidb--deploy 4.7G 1.3G 3.2G 29% /tidb/tidb-deploy
/dev/mapper/centos_server153-tidb--data 20G 13G 5.2G 72% /tidb/tidb-data
tmpfs 1.3G 0 1.3G 0% /run/user/0
// 直接在外围进数据快照
lvcreate -L 5G -s -n lv-mysql-snap01 /dev/centos_server153/tidb-data
lvcreate -L 5G -s -n lv-mysql-snap02 /dev/centos_server153/tidb-data
[root@server128 ~]# lvscan
ACTIVE '/dev/centos_server153/swap' [4.00 GiB] inherit
ACTIVE '/dev/centos_server153/root' [<175.71 GiB] inherit
ACTIVE '/dev/centos_server153/tidb-deploy' [4.88 GiB] inherit
ACTIVE Original '/dev/centos_server153/tidb-data' [19.53 GiB] inherit
ACTIVE Snapshot '/dev/centos_server153/lv-mysql-snap01' [5.00 GiB] inherit
ACTIVE Snapshot '/dev/centos_server153/lv-mysql-snap02' [5.00 GiB] inherit
//删除数据
rm /tidb/tidb-data/* -rf
umount /tidb/tidb-data/
//恢复数据
[root@server128 ~]# lvconvert --merge /dev/centos_server153/lv-mysql-snap02
Merging of volume centos_server153/lv-mysql-snap02 started.
centos_server153/tidb-data: Merged: 80.49%
centos_server153/tidb-data: Merged: 100.00%
//重新上线
mount /dev/mapper/centos_server153-tidb--data /tidb/tidb-data/
备份容灾总结
针对数据库的备份恢复存在多种方法，例如针对数据库的接入层备份恢复、针对数据库的服务层进行备份恢复、针对数据库的物理进行备份恢复。
以MySQL为例，支持接入层、服务层、物理层的备份恢复，重视锁处理生产数据的矛盾冲突。
接入层的备份有mysqldumper和mydumper，接入层在数据恢复的时候 ，需要进行昂贵的SQL解析，花费大量的时间，虽然 mydumper备份快，但是数据导入速度也不快。
服务层的备份导出例如CSV的规范式文件，再通过load data的方式进行导入，如果接入层的恢复是直路导入，那么服务层是旁路导入，旁路导入按照规律快速生成有序组织，避免SQL的消耗。
物理层的备份有Xtrabackup，它可以将把原有的MySQL相关物理文件迁移过来，技术层面重视已经持久化的数据和没有持久化的数据，通过redo回放数据，释放表空间尚未提交的脏页。经过清洗的数据文件可以马上拿来就用，不需要额外转换。
快照备份，MySQL支持LVM备份
TiDB同样支持接入层、服务层、物理层的备份恢复，主要通过快照处理生产数据的矛盾冲突。
接入层的备份有mysqldumper和mydumper,经过TiDB的适配二开，由于TiDB 分布式能力，资源能力潜力较大，间接也提升mysqldumper和mydumper的使用率
服务层的备份有Lightning导入和Dumpling导出，Lightning导入绕过接入层，直接在服务层导入 ，通过转化成KEV_VALUE形式，性能较快。
物理层的备份有BR工具，直接对TiKV 进行时间戳扫描，扫描后的文件转换成sst文件，如果要恢复数据文件，需要专业工具进行转换。
快照备份，TiDB支持LVM备份
在备份上的策略，MySQL积极与生产数据协同，达成一致，沟通的方式先上一个全局刷，让它们稍停一会儿。MySQL甚至有元数据锁，解决DDL层面数据结构稳定不变的锁机制。 而备份上TiDB的落地则是使用快照确定米已成炊的事实，在锁方面的应用较少，加大了存储成本，但是提升了性能。