数据恢复系列~恢复方案制定

一 简介:今天聊聊如何加速恢复你的数据

二 背景:上篇讲到数据恢复的重要性和一般思路.今天讲讲应该怎么做

三 角度:

1 方案1: 设定延迟时间,建立延时库

目标: 恢复24小时内的一切误操作

  恢复步骤:1 分析binlog确认误操作时间

         2  延时库进行指定节点复制

           普通复制 start slave until MASTER_LOG_FILE ='Relay_Master_Log_File', MASTER_LOG_POS =Exec_Master_Log_Pos；

           GTID复制 start slave until SQL_BEFORE_GTIDS ='96359478-a845-11e6-a3d6-000c296e817a:44';

    限制: 恢复有效时长取决于你设置的延时时间,一般设置为24小时

    缺点:需要付出硬件成本,增加维护成本

2 方案2: 利用备份进行恢复

目标:恢复全量备份有效期内-现阶段的一切误操作

   恢复步骤: 1 解压当天的全量备份

          2 分析binlog确认误操作时间

          3 建立恢复实例

1 目标主库拥有所需的全量binlog日志

             在从库设置过滤规则,只同步指定的库表,加快恢复速度

                    从库复制到指定位置后停止复制

                     2 拥有离线binlog全量备份

            1 将binlog伪装成relay-log进行消费

       缺点:时间耗费在解压备份和数据同步上,备份集越大,binlog相差越多,恢复越慢

3 方案3:完全依赖第三方工具binlog2sql/MyFlash等开源工具

目标:恢复短时间内针对库表的DML操作目标,DDL无法回滚

    恢复步骤: 1 利用开源工具分析binlog并生成回滚语句

  缺点:不支持DDL回滚

4 方案4:预防性工具inception

  简介:通过inception操作的DML语句能实现自动生成回滚语句,非常方便,省去了分析binlog的操作

  目标:研发自助工单的DML变更需求

    缺点: 1 不支持DDL操作 2 本身有限制(比如联表join更新,子查询更新等操作.建议避免)

四 总结

  1 针对研发主动提出的DML变更需求采用go-inception方式生成回滚语句

2 针对库表的删除操作建议DBA进行rename/dump方式进行保留,定期进行删除

3 针对程序的线上变更采用第三方binlog解析工具进行回滚

4 针对历史特定时间的数据恢复采用全量备份+binlog伪装方案(因为线上默认binlog并非全量保留,这个要注意,建议离线进行binlog备份)

5 针对大量的数据清理(非库表drop操作)采用pt-archiver进行归档,定期进行删除处理