mysql加快备份_MySQL优化三(备份与还原)

本章谈谈MySQL的备份和还原，外加一点点复制。

其中所谓的复制跟备份有点关系，因此放在这里记录下来，另一部分复制跟主、从库有关系，未来打算放进MySQL架构部分去记录，在本博看来主、从库不仅是架构级别，并且需要适当监控，因此独立一章，具体阐述。

备份和还原其实也是比较复杂的，譬如备份时不要影响生产环境的业务进行，还原时同时也应注意这点。

复制复制用途

《高性能MySQL》上列出了几点可供参考：

1)数据分布，简单来说就是多个库，需要同步

2)负载平衡，本博理解为读写分离

3)备份

4)高可用性和故障转移，数据库切换

5)测试MySQL升级，在从服务器上进行升级，之后测试，其实也是和正式环境隔离的一个方式。

以上可以看出所谓的复制，基本就是主从复制，正所谓有备无患，并且这些问题是确实存在的，因此复制尤为重要。

以上的问题，归结来说，主要是环境隔离和性能优化两个方面，以前使用单个数据库时，进行过一些比较危险的复制，例如停机维护，关闭服务器后直接拷贝数据库文件，或者直接使用备份脚本备份。这些都不是很合理的，因此，主从备份基本都是首选。

BTW，对于脚本备份，不同的数据库引擎必须要注意使用的脚本，下文会列出。主从复制工作原理

主从库的同步，牵涉到几个方面：

主库的SQL线程，记录bin log

从库的I/O线程，以二进制形式接受bin log，存为relay log

从库的SQL线程，执行主库的relay log

毫无疑问会略微影响性能，但是是必须的。

主从库其实比较简单， 涉及的命令及操作方式未来在架构中详细列出，亦或特立一章。

备份mysqldump命令

命令mysqldump 用于数据库的备份，只是注意几个参数，lock-table lock-all-table 用于进行表的锁，以达到固定时间点备份的目的，需要指出的是，如果锁表，必定会影响生产环境，除非在没人访问库表的情况下使用。

其他物理备份，需针对不同数据库引擎加以区分，例如 MyISM 可以使用mysqlhotcopy。 innodb则可能需要更复杂的工具和操作。

还有一种使用以来的操作系统进行LVM快照备份，需要考虑的比较多，可以参考相关文档。

本博认为最靠谱的还是主从备份，也就是使用bin log 进行备份，或者直接mysqldump 备份从库内容。

还原

对于物理备份， 直接粘贴复制的文件即可。

对于mysqldump备份下来的文件，其实也就是一堆insert 的SQL语句，使用mysql 命令即可。这里需要注意的是备份文件的大小，如果太大，可以分段导入。

如果有bin log， 可以进行时间点的还原，因此即使清空了所有数据，还是可以还原清空之前的数据。

InnoDB

InnDB是个非常健壮的数据库引擎，这里阐述一个或许和备份还原无关的机制，InnDB无论是在运行中，或者刚启动都会有一些特别的动作，例如它具有很多检验机制，来进行自我修复。在进行入库操作时，会使用缓存，放置内存中，也就是说磁盘上的物理文件，并非和内存中在同一时刻保持一致。

因此，从数据还原角度讲，还存在另一种情况，即并非从历史备份中还原，而是根据日志里的事务状态，把数据更新到数据文件，或者进行回滚工作。

心得

本博的一些心得，数据备份要常做，当然是在不影响生产环境的前提下。并且使用脚本来做，当然也有好的工具，但是，在*nix系统下，架构允许的情况下，还是自己多花时间，写点脚本吧。