如何优雅的备份和恢复Mysql数据库？

谢邀，个人认为从标题看，是个比较大而且值得数据库从业者思考的问题；从问题描述看，又是一个比较浅显的问题。

先从问题描述看，mysqldump 备份和恢复时往往会有各种错误，如何避免？mysqldump由于是逻辑备份，默认在备份期间会去检查各种备份对象的合法性，所以出现诸如表损坏，视图定义错误等问题，虽然可能不影响数据库的整体运行mssql数据库空间，但是备份会通不过。谨慎且推荐的做法就是挨个去根据报错处理，直到备份成功和一次数据恢复成功为止，粗暴一点的做法就是加--force强制忽略各种sql类型的报错，因为从理论上来说这些损坏或不合法的数据库对象，不备份也是可以接受和理解的。从答主上万实例的mysqldump备份失败情况分析来看，参考这个应该能解决99%的mysqldump失败

blog.csdn.net/cug_jiang126com/article/details/49359699

再从广度上来说，如何优雅的备份和恢复mysql数据库？

备份方式的选择

从备份期间是否停服看，热备还是冷备，这个我认为当今的现网运行的数据库系统基本不存在冷备份的场景了（除非是整个系统全部扑街，恢复数据前可能有必要copy一份数据），热备份且能够获取到一致性备份点的热备份是mysql备份系统必须具备的功能。

从备份文件的类型看，无论是逻辑备份还是物理备份，都有其优势和缺陷，都有其不可替代性，而往往逻辑备份的优势正好是物理备份的缺陷。在我看来逻辑备份最大的优势有两点

1 数据压缩率高(因为通常情况下会有不少index，或者碎片空间等，这个很占物理空间，而逻辑备份出来的逻辑sql就可以很大程度地节约这块空间)，这个在海量数据库场景下很重要，因为备份占用的空间成本，上传成本也不容忽视

2 备份灵活，兼容性强。打个比方，当一个单机数据库想做分库分表时，数据迁移阶段必然会涉及到一次类似逻辑备份，通过逻辑备份导入分布式数据库环境中(因为不可能通过传输物理备份文件到多个数据库节点)

以上2点也正是物理备份的劣势，而物理备份相对逻辑备份而言的优势也非常明显，备份速度快+恢复速度快，这两点可能在绝大部分场景下更重要，所以现在主流的备份方式应该是物理备份，虽然逻辑备份也存在一些多线程备份的开源工具比如mydumper，但备份速度通常还是不如物理备份。

当然，既然要优雅，在海量数据库备份系统中，我认为两种备份方式都应该支持，可以灵活设置，针对不同的备份方式再开发不同的恢复方式。除此以外，还需要考虑

0 备份和恢复期间对IO等系统资源消耗情况的把控，是否可以做到限速？

1 如何灵活地设置备份策略，比如备份周期和备份时间点的选择，是否可以在从库备份，备份上传到何处，选择什么压缩方式？

2 如何确认备份是否成功，哪一步骤出了问题，哪些步骤失败可以重试，哪些步骤失败不必重试？

3 如何确认成功的备份实际可有效还原？

4 再细一些，mysql为了获取一致性的备份点，必然会有一个flush tables with read lock的加全局锁的操作，如何控制该操作对运行中的实例的可能造成的恶劣影响？

5 再细一些，这个mysql实例是否开启了gtid，针对不同版本的mysql是否也需要有差异化对待？针对有无gtid等场景，备份和恢复策略其实也是有所不同的

.................

所以说，个人看来，要做到一个极致优雅的数据库备份和恢复系统其实很不容易，目前可能也只有公有云才会针对各种各样可能出现的场景和报错处理，将方方面面都考虑全了。

可参考大型备份系统设计

blog.csdn.net/cug_jiang126com/article/details/54926678

（编辑：海南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!