MySQL备份恢复深度优化计划
这是学习笔记的第 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天前数据恢复
· 恢复时长预测
· 异机恢复的文件只能选择最近一个;