MySQL之备份与恢复(十)

备份与恢复

备份和恢复工具

有各种各样的好的和不是那么好的备份工具。我们喜欢对LVM使用mylvmbackup做快照备份，使用Percona Xtrabackup(开源)或MySQL Enterprise Backup(收费)做InnoDB热备份。不建议对大数据量使用mysqldump,因为它对服务器有影响，并且漫长的还原时间不可预知。有一些备份工具已经出现多年了，不幸的是有些已经过时。最明显的例子是Maatkkit的mk-parallel-dump。它从没有正确运行，甚至被重新设计过好几次还是不行。另外一个工具是mysqlhotcopy，它适合于古老的MyISAM表。大部分场景下这两个工具都无法让人相信数据是安全的，它们会使人误认为备份了数据实际上却非如此。例如，当使用InnoDB的innodb_file_per_table时，mysqlhotcopy会复制.ibd文件，这会使一些人误认为InnoDB的数据已经备份完成。在某些场景下，这两个工具都对服务器有一些负面影响。如果你在2008或2009年时在看MySQL的路线图，可能听说过MySQL在线备份。这是一个可以用SQL命令来开始备份和还原的特性。它原本是规划在MySQL5.2版本中，后来重新安排在了MySQL6.0中，再后来，据后来所知被永久取消了。

MySQL Enterprise Backup

这个工具之前叫作InnoDB Hot Backup或ibbackup，是从Oracle购买的MySQL Enterprise中的一部分。使用此工具备份不需要停止MySQL，也不需要设置锁或中断正常的数据库活动(但是会对服务器造成一些额外的负载)。它支持类似压缩备份、增量备份和到其他服务器的流备份的特性。这是MySQL"官方"的备份工具。

Percona XtraBackup

Percona XtraBackup与MySQL Enterprise Backup在很多方面都非常类似，但它是开源并且免费的。除了核心备份工具外，还有一个用Perl写的封装脚本，可以提供更多高级功能。它支持类似流、增量、压缩和多线程(并行)备份操作。也有许多特别的功能，用以降低在高负载的系统上备份的影响。Percona XtraBackup的工作方式是在后台线程不断追踪InnoDB日志文件尾部，然后复制InnoDB数据文件。这是个轻量级侵入过程，依靠特别的检测机制确保复制的数据是一致的。当所有的数据文件被复制完，日志复制线程就结束了。结果是在不同的时间点的所有数据的副本。然后可以使用InnoDB崩溃恢复代码应用事务日志，已达到所有数据文件一致的状态。这一步叫作准备过程。一旦准备好，备份就会完全一致，并且包含文件复制过程最后时间点已经提交的事务。一切都在MySQL外部完成，因此不需要以任何方式连接或访问MySQL.包装脚本包含通过复制备份到原位置的方式进行恢复的能力。还有Lachalan Mulcahy的XtraBack Manager项目

mylvmbackup

Lenz Grimmer的mylvmbackup是一个Perl脚本，它通过LVM快照帮助MySQL自动备份。此工具首先获取全局读锁，创建快照，释放锁。然后通过tar压缩数据并移除快照。它通过备份时的时间戳命名压缩包。它还有几个高级选项，但总的来说，这是一个执行LVM备份的非常简单明了的工具

Zmanda Recovery Manager

适用于MySQL的Zmanda Recover Manger 或ZRM，有免费(GPL)和商业两种版本。企业版提供基于网页图形接口的控制台，用来配置、备份、验证、恢复、报告和调度。开源的版本包含了所有核心功能，但缺少一些额外的特性，例如基于网页的控制台。正如其名，ZRM实际上是一个备份和恢复管理器，而并非单一工具。它封装了自由的基于标准工具和技术，例如mysqldump、LVM快照和Percona XtraBackup等之上的功能。它将许多冗长的备份和恢复工作进行自动化。

mydumper

几名MySQL现在和之前的工程师利用他们多年的经验创建了mydumper，用来替代mysqldump。这是一个多线程(并发)的备份和还原MySQL和Drizzle的工具集，有许多很好的特性。大概有许多人会发现多线程备份和还原的速度是这个工具最吸引人的特色。尽管我们知道有些人在生产环境中使用，但我们还没有在任何产品中使用的经验

mysqldump

大部分在使用这个与MySQL一起发行的程序，因此，尽管它有缺点，但创建数据和Schema的逻辑备份最常见的选择还是mysqldump。这是一个通用工具，可以用于许多的任务，例如在服务器间复制表

mysqldump --host=server1 test t1 | mysql --host=server2 test
1

在前面展示几个用mysqldump创建逻辑备份的例子。该工具默认会输出包含创建表和填充数据的所有需要的命令；也有选项可以控制输出视图、存储代码和触发器。下面有一些典型的例子。

• 1.对服务器上所有的内容创建逻辑备份到单个文件中，每个库中所有的表在相同逻辑时间点备份:

mysqldump --all-databases > dump.sql
1

• 2.创建只包含Sakila示例数据库的逻辑备份:

mysqldump --databases sakila > dump.sql
1

• 3.创建只包含sakila.actor表的逻辑备份

mysqldump sakila actor > dump.sql 
1

可以使用 --result-file选项来指定输出文件，这可以帮助防止在Windows上发生换行符转换:

mysqldump sakila actor
1

mysqldump的默认选项对于大多数备份目的来说并不够好。多半要显示地指定某些选项以改变输出。下面是一些我们经常使用地选项，可以让mysqldump更加高效，输出更容易使用。

• –opt
  启用一组优化选项，包括关闭缓冲区(它会使服务器耗尽内存)，导出数据时把更多地数据写在更少的SQL语句里，以便在加载的时候更有效率，以及做其他一些有用的事情。更多细节可以阅读帮助文件。如果关闭了这组选项，mysqldump会把表写到磁盘之前，把他们都导出到内存里，这对于大型的表而言是不切实际的。
• –allow-keywords, -quote-names
  使用户在导出和恢复表时，可以使用保留字作为表的名字
• –complete-insert
  使用户能在不完全相同列的表之间移动数据
• –tz-utc
  使用户能在具有不同时区的服务器之间移动数据
• –lock-all-tables
  使用FLUSH TABLE WITH READ LOCK来获取全局一致的备份。
• –tab
  用SELECT INTO OUTFILE导出文件
• –skip-extended-insert
  使每一行数据都有自己的INSERT语句。必要时这可以用于有选择地还原某些行。它的代价是文件更大，导入到MySQL时开销会更大。因此，要确保只有在需要时才启用它。
  如果在mysqldump上使用–databases或–all-databases选项，那么最终导出的数据在每隔数据库中都一直，因为mysqldump会在同一时间锁定并导出一个数据库里的所有表。然而，来自不同数据库的各个表就微比是相互一致的。使用–lock-all-tables选项可以解决这个问题。对于InnoDB备份，应该增加–single-transaction选项，这会使用InnoDB的MVCC特性在单个时间点创建一个一致的备份，而不需要使用LOCK TABLES锁定所有的表。如果增加–master-data选项，备份还会包括在备份时服务器的二进制日志文件位置，这对基于时间点的恢复和设置复制非常有帮助，然而也要知道，获得日志位置时需要使用FLUSH TABLES WITH READ LOCK冻结服务器