接上篇：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级别；快照备份推荐云盘版实例，是云盘最高效与稳定的一种方式。
