接上篇:https://developer.aliyun.com/article/1224053?groupCode=supportservice
二、 数据库备份恢复原理
Xtrabackup备份流程如下:
首先,备份开始时会Fork一个进程,也会启动redo拷贝线程。拷贝时会监听redo log变换并写到xtrabackup log文件中,拷贝InnoDB引擎的文件。InnoDB数据拷贝完成,线程退出。
后续如果有非事务性引擎,需要为全局加FTWRL锁保证一致。全局备份完成后,通知redo拷贝线程停止并退出,执行unlock,全部执行完毕之后退出。
备份文件时,事务型引擎只需拷贝redo文件,但非事务型引擎表没有事务保证,也没有log,因此需要FTWRL锁来保证所有数据一致。
以上为2.4版本的流程,后续版本使用了lock table with fullbackup这样轻量级的锁,不再有全局锁定。
FTWRL主要的工作包括:备份非事务性引擎表,获取binlog位点、GTID、redo log、LSN、redo log刷盘。
增量备份时,会先找到上次备份的to_lsn,从此处开始备份增量数据,增量数据即binlog。
快照备份是基于存储或文件系统,不同类型的快照有不同的技术,本文主要介绍copy-on-write的原理。
首先,发起快照备份时,只需初始化指向于所有数据块元数据的指针。跟踪元数据变化,在覆盖之前将旧数据拷贝到预留的快照空间,更新快照指针到新快照卷中的数据即可。
数据更新后将数据拷贝到另外的地方,指针会随之更改。读取时,没有变更的数据从原先的地方读取,变动的数据从快照卷中读取,只需读取指针即可。
该方式的优势在于,如果数据不更新,则空间开销特别小;备份时只需创建指针,速度极快;持续时间短,也不存在其他锁,因此影响小。缺点在于,每次数据更新时都会将数据再复制一份到预留的快照卷中,因此对写入性能有轻微影响。
恢复到任意时间点的流程如下:
找到恢复时间点前最近的一个全量备份集,将全量备份集还原至新数据库,再应用binlog增量数据直到指定的时间点。Binlog里的标识位点有position、datetime、GTID等帮助恢复到任意时间点。
三种备份方式的对比:
• 备份对象:逻辑备份更精细,可以自定义表、库或某一条数据、某个条件字段的数据;物理备份为数据库实例以及DB级别,快照备份为数据库实例级别。
• 备份效率:逻辑备份最慢,需要经过MySQL Server层到存储引擎层将数据读出再存储;物理备份比较快,只需要拷贝文件,额外操作较小;快照备份最快,因为基于存储,无需拷贝很多数据,只需生成快照指针。
• 恢复效率:逻辑备份需要将备份出的一条条数据应用到其他库中,因此执行特别慢;而物理备份只需做recover,备份恢复很快;快照备份只需在存储里进行,只需要做快照指针转化,因此恢复速度也很快。
• 备份影响:逻辑备份执行时间很长,开销很大,不仅有锁,还存在CPU等资源抢占,因此影响最大。物理备份和快照备份影响较小。
• 备份数据量:逻辑备份不会有数据碎片,因此比原库更小;物理备份与原库一致;而快照备份最小,因为只需要预留快照卷,保留更新数据的前镜像即可。
• 兼容性:逻辑备份可以恢复到绝大部分存储引擎;物理备份依赖于数据库版本架构,需要保持一致才可以存储;快照备份依赖于存储或文件系统,但是当前云上提供了下载快照备份的功能,可以将快照进行转换之后下载。
• 操作复杂性:逻辑备份最简单,只需要一个命令或简单的SQL;物理备份比较复杂,不同的工具会有很多参数,并且非常依赖于目标库的环境;快照备份原理比较复杂,但因为基于存储提供了现成的能力,因此操作较为简单。
• 数据库规模推荐范围:逻辑备份一般建议MB到百GB级别,大于该范围的开销过大,不推荐;物理备份是主流的备份方式,最大可到TB级别;快照备份推荐云盘版实例,是云盘最高效与稳定的一种方式。