数据库物理备份
MySQL的物理备份包含了全量备份、增量备份、逻辑事务日志备份。
全量备份
将数据库实例下的所有数据文件，做一次完整的备份。并可以基于全量备份的数据，恢复完整的数据库实例。
增量备份
以某次备份为基础，只备份在该次备份之后，发生变化的差异数据内容。增量备份的数据不是完整的数据库实例数据，必须结合全量备份一起使用，才能恢复出完整的数据库实例。
增量备份作为全量备份和逻辑事务日志备份的补充，有几个明显的优点。
- 只备份有差异的数据，相比全量备份，数据量少，成本更低。
- 基于文件备份，对数据库操作风险更低。
- 基于文件物理恢复，相比逻辑事务日志恢复，成功率高，恢复RTO更低。
逻辑事务日志备份
MySQL的binlog记录了实例的逻辑事务日志。全量、增量备份只能恢复到备份的时刻，如果需要基于时间点的数据恢复（PITR），需要结合binlog回放日志到PITR时间点。
业界常见数据库增量备份方式
MySQL——page数据页扫描
MySQL下获取增量数据，需要通过Percona提供的的Xtrabackup工具，需要对数据库做全库文件扫描，挨个page比对LSN，通过LSN判断该page是否发生更改，来决定是否对这个page进行备份。
使用过Xtrabackup增量备份的朋友应该都发现一个问题，虽然一次增量备份产生的数据量远小于全量备份，但备份过程产生的磁盘读IO却与全量备份相当，这是因为都要对所有文件遍历读取一次，读的总数据量是一样的。而且增量备份对磁盘读IO的压力会高于全量备份，逐page读取比对，如果不是需要备份的增量page数据，需要立刻读取下一个page，这样两次page读取的间隔会小于全量备份，使的磁盘读IO压力更高。
Percona-Server——CPT（Change Page Tracking）变化页追踪
Percona Server版的MySQL在内核支持将变化的数据page，记录到位图中，在进行增量备份时，可以直接从位图记录中获取两次备份之间的变化的page信息，避免对实例文件的遍历读取来获取增量page。
Oracle——BCT（Block Change Tracking）块变更追踪
Oracle BCT记录数据文件里每个数据块block的变化，采用位图记录保存，增量备份时，通过位图信息，直接获取哪些数据块block发生了变化，避免全库扫描，加速了增量备份，降低了读IO量。
Oracle官网介绍：
https://docs.oracle.com/database/121/ADMQS/GUID-3BAA0D48-CA35-4CD7-810E-50C703DC6FEB.htm
Oracle的BCT（Block Change Tracking）是从10g版本开始支持。
快照增量备份——存储BCT（Block Change Tracking）块变更追踪
数据库实例运行在支持快照的存储上，实例备份则对存储进行快照操作。通过快照备份接口可以实现同一个盘的一次全量永久增量的备份，从而获得该盘上的数据库实例的增量数据，例如阿里云RDS通过云盘EBS快照接口，可以进行全盘的全量和增量数据库备份。
通用增量备份——文件系统抓取
通过对文件系统进行IO Capture的方式，获取到数据库文件的变化情况，从而获取增量数据，这种方式较为通用，但是对该模块的稳定性要求较高。
RDS MySQL高频物理备份
伴随着用户业务的快速增长，数据的操作更加频繁，数据库数据量越来越大。对实例备份成本控制，实例恢复RTO有着更高的需求。所以RDS MySQL在全量备份的基础上，引入了增量备份，推出高频物理备份功能。
RDS MySQL本地盘实例完成一次基于时间点恢复（PITR），需要先恢复全量备份集，然后回放从全量备份时间点到PITR时间点之间所有的binlog日志。如果两个时间点距离较远，达到天级别，binlog数据量可能会非常多，而binlog的恢复速度较慢，回放所有binlog日志会需要一个很长的时间，整个恢复任务绝大部分时间都消耗在回放binlog日志了，整个实例的恢复RTO会非常高。
降低恢复RTO的一个关键是，如何减少binlog日志回放耗时，降低需要回放的binlog日志数据量是一个不错的方式。实现更高的备份频率，备份频率由天级别，降低到小时级别，可以直接降低需要回放的binlog日志数量。
RDS MySQL本地盘实例备份，最低备份频率是一天一次全量备份。如果想降低恢复RTO，就需要提高备份频率，只能手动或者定时调用API发起全量备份。过于频繁的发起全量备份，又会使得产生的备份数据存储费用成倍数的增加，如何平衡恢复RTO与备份存储费用，真的是鱼与熊掌不可兼得吗？
现在他来了，RDS MySQL高频物理备份，同时兼得低恢复RTO与低备份存储费用，鱼与熊掌兼得。
RDS MySQL高频物理备份（小时级别物理备份）
MySQL高频物理备份，在全量备份基础上，引入增量备份，最低可以实现1小时级别的物理备份。到指定高频物理备份周期，会发起一次增量备份，增量备份产生的数据量会远小于全量备份（数据量多少数据库使用的业务形态有关）。
RDS高频物理备份——极致物理增量备份性能
想要提高MySQL物理增量备份的性能，如何降低物理增量备份的IO量是关键问题。如果能够在每次增量备份时，知道哪些数据page发生过变化，而不需要全数据库扫描的方式，看来是非常不错的方法。MySQL的redo log，就可以帮助实现这一方法。
MySQL redo log是InnoDB存储引擎特有的日志。又称重做日志。用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。redo log的每一个record格式如下，space_id代表了该record修改的表，offset表示修改了表中的page编号。
RDS MySQL高频物理备份，引入基于Redolog的CBT(Changed Block Tracking)技术，也称CPT(Changed Page Tracking)。在数据库实例运行时，可实时分析redo log数据，下次增量备份可以通过解析的数据，直接获取发生过变化的page数据。通过这个方式，避免了扫描数据库数据文件造成的磁盘IO开销，同时节省了备份时间。
相比数据库文件逐个page扫描，借助CBT技术，可以减少90+%的读IO，节省90+%的备份时间。
RDS MySQL高频备份恢复（快速恢复，RTO降低）
在高频物理备份场景下，备份恢复增加了一个增量恢复阶段，先恢复全量备份数据，然后将后续的增量数据合并到全量数据上去，最后回放最后一次增量备份时间点到PITR时间点之间的所有binlog日志。
全量+定期增量的物理备份方式，降低了物理备份时间点到PITR时间点的时间差，最低可以将降低到一小时内，最多回放1小时内的binlog，大幅降低所需要回放的binlog日志数据量。但是增加的增量恢复的阶段也有时间消耗呢？不要怕，增量备份恢复是物理数据恢复，不同于binlog逻辑恢复。
binlog日志回放的速度难于预估，需要MySQL处于运行状态下去逻辑执行SQL，与实例规格、使用方式、数据库版本、SQL类型等都有关系，恢复速度不稳定。物理恢复不需要MySQL处于运行状态下，恢复只受限于网络带宽与磁盘IO，是物理文件拷贝，与逻辑数据无关，恢复速度稳定，可以轻松达到数倍以上的恢复速度，增量恢复阶段增加的时间消耗，远远小于节省的binlog日志回放的时间消耗。
写在最后：
- 如果您对RDS有更高频率的备份需求，请使用高频物理备份
- 如果您对RDS有更低RTO的恢复需求，请使用高频物理备份
了解如何使用RDS高频物理备份，请点击「阅读原文」查看更多内容
/ End /
