MySQL之备份与恢复(四)
备份与恢复
存储引擎和一致性
3.复制
从备库中备份最大的好处是可以不干扰主库，避免在主库上增加额外的负载。这是一个建立备库的好理由，即使不需要用它做负载均衡或高可用。如果钱是个问题，也可以把备份用的备库用于其他用户，例如报表服务——只要不对其做写操作，以确保备份不会修改数据。备库不必只用于备份的目的；只需要在下次备份时能及时跟上主库，即使有时因作为其他用途导致复制延时也没有关系。当从备库备份时，应该保存所有关于复制进程的信息，例如备库相对于主库的位置。这对于很多情况都非常有用:克隆新的备库，重新应用二进制日志到主库上以获得指定时间点的恢复，将备库提升为主库等。如果停止备库，需要确保没有打开的临时表，因为它们可能导致不饿能重启备库。故意将一个备库延时一段时间对于某些灾难场景非常有用。例如延时复制一小时，当一个不期望的语句在主库上运行后，将有一个小时的时间观察到并在中继日志中方之前停掉复制。然后可以将备库提升为主库，重放少量的日志事件，跳过错误的语句。这比后面要讨论的指定事件点的恢复技术可能要快得多。Percona Toolkit中pt-slave-delay工具可以帮助实现这个方案。
备库可能与主库数据不完全一样。许多人认为备库是主库完全一样的副本，但以经验，主库与备库数据不匹配是很常见，并且MySQL没有方法检测这个问题。检测这个问题的唯一方法是使用Percona Toolkit中的pt-table-checksum之类的工具。拥有一个复制的备库可鞥在诸如主库的硬盘烧坏时提供帮助，但却不能提供保证。复制不是备份。
管理和备份二进制日志
服务器的二进制日志时备份的最重要因素之一。它们对于基于时间点的恢复是必需的，并且通常比数据要小，所以更容易进行频繁的备份。如果有某个时间点的数据备份和所有从那时以后的二进制日志，就可以重放自上次全备以来的二进制日志并"前滚"所有的变更。MySQL复制也使用二进制日志。因此备份和恢复的策略经常和复制配置相互影响。二进制日志很"特别"。如果丢失了数据，你一定不希望同时丢失了二进制日志。为了让这种情况发送的几率减少到最小，可以在不同的卷上保存数据和二进制日志，即使在LVM下生成二进制日志的快照，也是可以的。为了额外的安全起见，可以将它们保存在SAN上，或用DRBD复制到另外一个设备上。经常备份二进制日志是个好主意。如果不能承受丢失超过30分钟数据的价值，至少需要每30分钟就备份一次。也可以用一个配置–log_slave_update的只读备库，这样可以获得额外的安全性。备库上日志位置与主库不匹配，但找到恢复时正确的位置并不难。最后，MySQL5.6版本的mysqlbinlog有一个非常方便的特性，可以连接到服务器上来实时对二进制日志做镜像，比起运行一个mysqld实例要简单和轻便，它与老版本时向后兼容的。
二进制日志格式
二进制日志包含一系列的事件。每个事件有一个固定长度的头，其中有各种信息，例如当前时间戳和默认的数据库。可以使用mysqlbinlog工具来查看二进制日志的内容，打印一些头信息。下面是一个输出的例子。
$ mysqlbinlog mysql-bin.000002
第一行包含日志文件内的偏移字节值
第二行宝行以下几项:
- 1.事件的日期和事件，MySQL会使用它们来产生SET TIMESTAMP语句。
- 2.原服务器的服务器ID,对于防止复制之间无限循环和其他问题是非常有必要的。
- 3.end_log_pos，下一个事件的偏移字节值。该值对一个多语句事务中的大部分事件是不正确的。在此类事务过程中，MySQL的主库会复制事件到一个缓冲区，但这样做的时候它并不知道下个日志事件的位置
- 4.事件类型。本例中的类型是Query,但还有许多不同的类型
- 5.原服务器上执行事件的线程ID，对于审计和执行CONNECTION_ID()函数很重要。
- 6.exec_time，这是语句的时间戳和写入二进制日志的时间之差。不要依赖这个值，因为它可能在复制落后的备库上会有很大的偏差
- 7.在原服务器上事件产生的错误代码。如果事件在一个备库上重放时导致不同的错误，那么复制将因安全预警而失败。
后续的行包含重放变更时所需的数据。用户自定义的变更和任何其他特定设置，例如当语句执行时有效的时间戳，也将会出现在这里。如果使用的是MySQL5.1中基于行的日志，事件将不再是SQL.而是可读性较差的由语句对表所做变更的"镜像"
安全地清除老的二进制日志
需要决定日志的过期策略以防止磁盘被二进制日志写满。日志增长多大取决于负载和日志格式(基于行的日志回导致更大的日志记录)。我们建议，如果可能，只要日志有用就尽可能保留。保留日志对于设置复制、分析服务器负载、审计和从上次全备按时间点进行恢复，都很有帮助。当决定想要保留日志多久时，应该考虑这些需求。
一个常见的设置是使用expire_log_days变量来告诉MySQL定期清理日志。这个变量直到MySQL4.1才引入;在此之前的版本，必须手动清理二进制日志。因此，你可能看到一些用类似下面的cron项来删除老的二进制日志的建议。
0 0 * * * /usr/bin/ find /var/log/mysql -mtime +N -name "mysql-bin.[0-9]*" | xargs rm
尽管这是在MySQL 4.1之前清除日志的唯一办法，但在新版本中不要这么做！用rm删除日志会导致mysql-bin.index状态文件与磁盘上的文件不一致，有些语句，例如SHOW MASTER LOGS可能会受到影响而悄然失败。手动修改mysql-bin.index文件也不会修复这个问题。应该用类似下面的cron命令
0 0 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"
expire_logs_days设置在服务器启动或MySQL切换二进制日志时生效，因此，如果二进制日志从没有增长和切换，服务器不会清除老条目。此设置时通过查看日志的修改事件而不是内容来决定哪个文件需要被清除。
备份数据
大多时候，生成备份有好的也有差的方法——有时候显而易见的方法并不是好方法。一个有用的技巧时应该最大化利用网络、磁盘和CPU的能力以尽可能快地完成备份。这是一个需要不断取平衡的事情，必须通过实验以找到"最佳平衡点"
生成逻辑备份
对于逻辑备份，首先要意识到的是它们并不是以同样方式创建的。实际上有两种类型的逻辑备份:SQL导出和符号分割文件。
- 1.SQL导出
SQL导出是很多人所熟悉的，因为它们是mysqldump默认的方式。例如，用默认选项导出一个小表将产生如下输出:
可以是如下命令:
mysqldump -u root -p sakila actor > myactor.sql
导出文件包含表结构和数据，均以有效的SQL命令形式写出。文件以设置MySQL各种选项的注释开始。这些要么是为了使恢复工作更高效，要么使因为兼容性和正确性。接下来可以看到表结构，然后是数据，最后，脚本重置在导出开始时变更的选项。导出的输出对于还原操作来说是可执行的。这很方便。但mysqldump默认选项读与生成一个巨大的备份却不是太适合。mysqldump不是生成SQL逻辑备份的唯一工具。例如，也可以用mydumper或phpMyAdmin工具来创建。想指出的是，不是某一个特定的工具有多大的问题，而是做SQL逻辑备份本身就有一些缺点。下面是主要问题点:
- 1.Schema和数据存储在一起
如果想从单个文件恢复这样做会非常方便，但如果只想恢复一个表或指向恢复数据就很困难了。可以通过导出两次的方法来环节这个问题——一次只导出数据，另外一次只导出Schema——但还会有下一个麻烦 - 2.巨大的SQL语句
服务器分析和执行SQL语句的工作量非常大，所以加载数据时会非常慢 - 3.单个巨大的文件
大部分文本编辑器不能编辑巨大的或者包含非常长的行的文件。尽管有时候可以用命令行的流编辑器——例如sed或grep——来抽出需要的数据，但保持文件小型化仍然是更合适的 - 4.逻辑备份的成本很高
比起逻辑备份这种从存储引擎中读取数据然后通过客户端/服务器协议发送结果集的方式，还有其他更高效的方式
这些限制意味着SQL导出在表变大时可能变得不可用。不过，还有另外一个选择;导出数据到符号分割的文件中