备份恢复注意事项（持续更新）

生产环境mysql复制架构一般是M-M结构（主库-备库），在做数据库拆分、硬件升级、扩容的方面都需要通过备份集来恢复出新备库（M-M-S）或级联备库（M-M-S1-S2），在这个过程中遇到很多问题，和大家分享一下

1. mysqldump备份集恢复，当存在myisam表情况下恢复后relay master binlog时会出现duplicate [key|event],其实恢复是成功的，只需要skip slave error即可，set global slave_exec_mode=IDEMPOTENT;stop slave;start slave;当slave同步超过备份结束时间点后执行show slave status\G;set global slave_exec_mode=STRICT;show slave status\G;复原即可
2. mysqldump备份集恢复，--default-character-set的设置也很重要，一定要与数据编码一致，数据具体编码需要登上实例分析，一般情况下character_set_client、character_set_connection、character_set_results是一致的，character_set_server作为建库建表默认缺省字符集，还要看具体表的字符集设置，当表字符集和（client、connection、results）不一致时，就需要分析表中数据真正的字符集编码，--default-character-set='charset' 以数据编码为准，如实例上表数据字符集不一致时会比较麻烦，暂时未遇到
   
3. 备份集失效也是要重点关注的，如备份中心空间慢，备份过程报错，检查机制可能随着备份工具不断优化调整而变得失效，需要有完善的检查机制来保证，数据的最后一道保障
4. 备份往往只关注备份集本身的可用性，如果备库的slave error或主备数据已经不一致的，从备库获取的备份集也是无效的
5. 当恢复过程没问题，准备拉master binlog时，发现找不到binlog pos了，master空间始终是有效的，需要定期purge binlog，当TPS维持高水位时，binlog量也会很大

• 需要及时清理，以免空间爆掉
• 备库会slave delay,导致恢复后的新备库找不到master binlog pos（slave delay+新备库恢复时间
• binlog异地备份和复用才是王道