公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2018-11-12 23:50:33 · 原文链接

这是学习笔记的第 1800篇文章

备份恢复之前和同事投入了一些精力来完善，算是走上了平台化对接的一个开始，在满足功能的前提下，能够基本实现数据全备，增备和DML闪回，但是在性能和可控性方面还是存在不少的改进之处，最近梳理了下已有的备份恢复策略，准备在这个方面能有一定的成绩。

1.备份恢复技术选型

·  备份分为物理备份和逻辑备份，目前逻辑备份的使用存在问题，不够灵活。

·  定制灵活的备份策略，数据量小（暂定小于10G）,使用逻辑备份+压缩，其他使用物理备份。 

·  逻辑备份备份表结构，需要完善表结构恢复步骤，后续可以补充数据生命周期管理，通过对比获得数据属性变化明细。

·  逻辑备份工具不局限于mysqldump,可以调研mydumper,充分测试，以提高性能为目标

2 备份恢复元数据

·  备份元信息和实例元信息需要统一存放;

·  梳理目前遗漏的主从集群备份，为了减少主库压力，物理备份在从库端完成

·  补充目前缺少的单点实例备份，目前暂定Infobright,TokuDB的从库暂不使用物理备份，其他业务包括测试环境，大容量环境都需要做好数据备份。

·  补充完善数据恢复的元数据设计

·  接入备份配置时，可以根据历史备份情况（比如时长，备份日志量）进行计算

3 MySQL备份流程

·  备份时间可以做到时间窗口统一调度

·  binlog2sql的取binlog日志还需到线上分析无法从Binlog server中取出;

·  梳理已有的binlog备份现状，查漏补缺，思路和备份数据稽核一致，binlog备份在从库端，需要充分利用binlog备份配置数据。

· 支持单库单表备份

· 备份看板数据需要丰富

· Binlog和备份下沉至HDFS，和大数据对接两个接口，一个是数据推送接口，一个是数据提取接口。

· Binlog备份需要定制和改进binlog2sql，目前的瓶颈在于python解析binlog效率较低，需要提高恢复效率

· Binlog2sql目前仅在mysql 5.7版本使用，需要补充适用在MySQL通用环境中

· 需要补充备份结果集的周期清理，通过灵活的配置来触发。

4 MySQL恢复流程

·  恢复时间可用，保证根据数据量和日志量，恢复控制在1个小时以内;

·  恢复的关键节点日志无法展示;

·  异机恢复脚本无法做到完全可控，补齐binlog时时间过长，中间可能出现问题，还需要更灵活;

·  恢复后数据库需要手动修改配置才可上线，如GTID，bp size，serverid，主从同步自动搭建;

·  数据恢复后加入MHA的考虑

·  对7天前数据恢复

·  恢复时长预测

·  异机恢复的文件只能选择最近一个;