前言
随着互联网行业的飞速发展，数据指数级增长，以及对应用系统服务的可用性要求越来越高。数据库灾难恢复时间直接影响业务系统的可用性，根据所涉及功能模块的不同会对公司产生不同程度的损失。如若发生了数据库灾难，必然希望数据不会丢失(RPO=0)，而且能尽快恢复(RTO 越小越好)。故而催生出了对数据库灾难恢复技术的强烈需求。
本篇文章主要介绍了数禾在MySQL数据库灾难恢复方面的探索和实践。
目录：
1. 背景
1.1 名词解释
1.2 数据库灾难分类
2. 数据库灾难恢复技术的发展
2.1 单实例
2.2 副本集模式
2.2.1 副本集复制模式
2.2.2 延迟副本集
3. 通用方案整合及改进
3.1 工单平台 - 流程和校验规则控制风险
3.2 备份策略和双区高可用
3.3 各场景数据库灾难恢复对比
4. 如果还是发生了？
4.1 全量恢复 - xtrabackup
4.1.1 备份逻辑(简化)
4.1.2 恢复逻辑
4.2 binlog恢复 - binlog2sql
5. 总结与展望
#01
背景
1.1名词解释
RTO（RecoveryTime Object）：恢复时间目标指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。
RPO（Recovery Point Object）：恢复点目标，衡量灾难发生后会丢失多少生产数据的指标。可简单的描述为设施能容忍的最大数据丢失量。
1.2 数据库灾难分类
数据库灾难发生分为两个层面：逻辑层面和物理层面。
逻辑层风险对应库，表，实际的生产数据的一些误操作，发生的原因大致如下:
应用系统BUG导致数据错误修改；
系统维护时产生的误操作，如迁移或应用下限时误删库表。
物理层风险对应硬件资源故障亦或者是地震，海啸等一些自然灾害。
基于以上两个层面，本文接下来将介绍MySQL数据库单节点与副本集合概念，从数据库容灾架构上给出一些设计优化思路，最后回归实践。探讨各个阶段实际遇到的一些问题和解决方案。
#2
数据库灾难恢复技术的发展
本章介绍单实例和副本集模式实例的基本概念，存在的问题以及如何优化。
2.1单实例
图1
单实例场景只有一台数据库实例对外提供服务对数据的唯一保障在于数据库全量的备份和对增量binlog 的备份。然而存储在本机的备份文件可能存在安全性问题(发生物理层面风险将导致备份文件同样损毁)，通常我们会将备份的文件存储在别的服务器或共享存储上来提升备份文件的安全性。
单机实例的备份存在几个问题：
为解决上述问题，通常我们都会选择副本集模式来对外提供服务。下面介绍副本集模式的概念。
2.2 副本集模式
副本集是一个简单的数据库同步备份的集群技术：
在数据库集群中主实例只有一台；
从实例实时同步主实例的数据变动。
图2
因为是多台服务器，我们可以在从实例上进行备份，这样能够解决单实例下备份消耗资源过高影响正常业务响应的问题。同时也可以解决发生物理层面风险时，如果当前的主实例发生故障损坏，能够将从实例提升成为主实例对业务进行承接来达到快速对业务进行恢复的需求。最后对于压力特别大的业务场景，从实例也可以对外提供服务，来实现读写分离的业务需求场景。
简单的副本集场景可以解决单实例存在的几个问题，但是同时自身也会引出新的问题：主从实例的延迟，在主实例发生物理层面风险时丢失数据。
我们可以从几个方面来对延迟问题进行优化：
行级别小事务；
优化参数加快从实例应用日志并发；
副本集复制模式的调整。
以下小节侧重MySQL从架构上如何解决主从实例延迟导致的数据丢失问题(即上述第3点)。
2.2.1 副本集复制模式
默认情况下的同步模式存在数据延迟的可能，如果这个时候发生实例宕机存在数据丢失的风险，通过副本集模式的优化，可以避免这类问题。下面是副本集复制模式的介绍。
副本集使用增强半同步复制模式确保了主实例发生故障损坏时数据不会丢失，但是发生逻辑层面风险时（错误的delete,drop）数据会被实时的应用到副本实例中。我们可以设置副本实例的延迟时间（通常设为延迟一天,根据实际需求可调整），即副本实例的实例数据是一天前主实例的数据。
2.2.2 延迟副本集
图3
T1时刻为正常延迟副本集模式的状态，副本实例的数据是一天前的主实例的数据；在T1.5时刻发生误操作，时间已经到了T2时刻；T3时刻调整副本实例的数据到T1.5时刻之间；T4时刻在副本实例将误操作的对象迁回，此时完成了数据库的修复。
通过增强半同步确保实例发生故障时数据不丢失，配合延迟功能能将数据恢复至任意时刻。
这一部分简单介绍了单实例和副本集模式的概念，单机实例存在的问题，副本集是如何解决的，以及副本集扩展的功能。
#3
通用方案整合及改进
数据库方面做的是灾难发生后如何进行修复，如果在源头控制住风险，就可以降低风险发生的概率。第一部分通过流程和SQL语句规则校验控制住部分风险，第二部分使用副本集高可用和完善的备份策略来确保任何灾难场景下数据的可恢复性。
3.1工单平台 - 流程和校验规则控制风险
图4
第一部分通过人员复核工单和工单平台规则来避免误操作的发生。研发提交工单，工单平台会进行风险操作规则校验(没有where条件的删除，drop操作会被拒绝通过)；校验通过后执行SQL，执行SQL前会对相应的操作生成回滚SQL用来应对误操作后的回滚。
通过流程上的控制，可以将逻辑层风险(DML)降到最低，即便发生了也可以快速进行回滚修复(工单执行前会被操作的数据进行备份)；库或表的删除考虑其恢复难度，不会直接进行删除，通过重命名表或库名，保留一段时间周期确认没有影响后才会进行真正的删除。
3.2备份策略和双区高可用
通过上部分工单平台可以防范大部分误操作。但还有发生的可能，如：工单平台删除数据备份失败，删除的表数据还有其他用途需要进行恢复。
好的备份策略和生命周期设计可以加快数据库灾难发生时恢复数据的速度。
备份策略：每周进行三次全量备份，增量备份通过对binlog日志进行备份实现。
备份的生命周期：备份按照备份数据使用概率和生命周期分为三级，一级备份用来响应快速恢复，二级备份存储到异地扩展容灾属性，三级备份转储到冷归档存储中用来应对审计和一些业务上的特殊需求。
使用这样的生命备份策略在成本和收益之间，取得了一个较好的平衡。
高可用方面，使用RDS双区高可用版本，隐藏实例与主实例不在同区域内，避免同区实例同时发生问题造成的服务不可用。
工单平台规则校验搭配数据库实例备份与高可用技术在发生数据库灾难的时候覆盖了所有场景，确保能尽快的将数据库恢复进行正常的业务访问。
3.3各场景数据库灾难恢复对比
测试场景限制在单表50G小于5000万行场景下，大数据集场景下时间会变长。
在流程控制前提下对比单机模式和副本集模式下的RTO和RPO，副本集模式可以极大的提升发生物理层面风险的恢复时间。
#4
如果还是发生了？
在前面措施都失效的情况下，我们只能从最后的手段备份文件中恢复出全量和增量数据，接下来将介绍备份的全量恢复和增量binlog反解析。
4.1全量恢复 - xtrabackup
Xtrabackup是由percona开源的免费数据库热备份软件，它能对InnoDB数据库存储引擎的数据库非阻塞地备份。对于MySQL的备份不管是云上还是自建机房的数据库备份，xtrabackup通常都是首选。
本文章着重介绍恢复的流程和恢复的实际过程。
4.1.1备份逻辑(简化)
备份开始，xtrabackup 同时起了两个线程，一个线程进行全量数据的拷贝，另一个线程进行备份期间数据改动重做日志的拷贝，全量数据文件拷贝完成后，线程1和线程2推出，备份完成。
图5
4.1.2恢复逻辑
图6
恢复的过程分为3步：
将全量数据拷贝回数据目录；
应用重做日志；
启动mysqld 服务。
4.2binlog恢复 - binlog2sql
binlog2sql是一款比较常用的数据恢复工具，可以通过它从MySQL binlog解析出你要的SQL，并根据不同选项，可以得到原始SQL、回滚SQL。
binlog反解析：
图7
#5
总结与展望
数据库灾难恢复由单实例到副本实例的，一步步优化上一步技术方案的不足点，最终实现了尽可能减少误操作尽可能快速恢复，同时平衡了成本与效用，通过冷归档存储降低备份文件的存储费用同时也延长了备份文件的存储时间。整体方案优化过程可以分为以下四个阶段：
虽然我们对方案进行了各种优化，但对于一些单表特别大的场景来说灾难恢复时间还是偏长。而业界普遍采用了分表分库的工具来切分单表的大小，也有迁移分布式数据库的实际场景。
分库分表工具能够解决大表出问题影响的数据范围，提高高并发场景下对数据库表写入读取速度，但是对分布式事务和聚合多库数据支持不是很友好。
分布式数据库由数据库本身实现分布式锁，对表数据的切分和SQL结果集的聚合由分布式数据库本身实现。同时支持在线水平线性弹性扩展，故障自恢复的高可用等特性。
目前，研发团队在进行分表分库的改造，同时我们也在积极的对分布式数据库进行调研，愿在后续的篇目中与大家进行分享。
点击下方公众号
加入数禾科技
