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天前数据恢复 · 恢复时长预测 · 异机恢复的文件只能选择最近一个;