备份与恢复

从备份中恢复

更高级的恢复技术

复制和基于时间点的恢复使用的是相同的技术:服务器的二进制日志。这意味着复制在恢复时会是个非常有帮助的工具，哪怕方式不是很明显。下面将演示一些可以用到的方法。这里列出来的不是一个完整的列表，但应该可以为你根据需求设计恢复方案带来一些想法。记得编写脚本，并且对恢复过程中需要用到的所有技术进行预演。shijian

• 1.用于快速恢复的延时复制
  在前面已经提到，如果有一个延时的备库，并且在备库执行问题语句之前就发现了问题，那么基于时间点的恢复就更快更容易了。恢复的过程与前面说的有点不一样，但思路是相同的。停止备库，用START SLAVE UNTIL来重放事件直到要执行问题语句。接着，执行SET GLOBAL SQL _SLAVE_SKIP_COUNTER=1来跳过问题语句。如果想跳过多个事件，可以设置一个大于1的值(或简单地使用CHANGE MASTER TO 来前移备库在日志中的位置)。然后要做的就是执行START SLAVE,让备库执行完所有的中继日志。这样就利用贝克u完成了基于时间点的恢复中所有冗余的工作。现在可以将备库提升为主库，整个恢复过程基本上没有中断服务。即使没有延时的备库来加速恢复，普通的备库也有好处，至少会把主库的二进制日志复制到另外的及其上。如果主库的磁盘坏了。备库上的中继日志可能就是唯一能够获取到的最接近主库二进制的东西了
• 2.使用日志服务器进行恢复
  还有另外一种使用复制来做恢复的方法:设置日志服务器。我们感觉复制比mysqlbinlog更可靠，mysqlbinlog可能会有一些导致异常行为的奇怪的Bug和不常见的情况。使用日志服务器进行恢复比mysqlbinlog更灵活更简单，不仅因为START SLAVE UNTIL选项，还因为那些可以采用的复制规则(replicate-do-table)。使用日志服务器，相对其他的方式来说，可以做到更复杂的过滤。例如，使用日志服务器可以轻松地恢复单个表。而用mysqlbinlog和命令行工具则要困难得多——事实上，这样做太复杂了，所以我们一般不建议进行尝试。假设粗心的开发人员像前面地例子一样删除了同样地表，现在想恢复此误操作，但又不想让整个服务器退到昨晚地备份。下面是利用日志服务器进行恢复地步骤:
• 2.1 将需要恢复的服务器叫作server1
• 2.2 在另外一台叫作server2的服务器上恢复做完的备份。在这台服务器上运行恢复进程，以免在恢复时犯错而导致事情更糟
• 2.3 按照前面的做法设置日志服务器来接收server1的二进制日志(复制日志到另外一个服务器并设置日志服务器是个好象发，但是要格外注意)
• 2.4 改变server2的配置文件，增加如下内容:

replicate-do-table=sakila.payment

• 2.5 重启server2,然后用CHANGE MASTER TO来让它成为日志服务器的备库。配置它从昨晚备份的二进制日志坐标读取。这时候切记不要运行START SLAVE
• 2.6 检测server2上的SHOW SLAVE STATUS的输出，验证一切正常。要三思而行！
• 2.7 找到二进制日志中问题语句的位置，在server2上执行START SLAVE UNTIL来重放事件直到该位置。
• 2.8 在server2上用STOP SLAVE停掉复制进程。现在应该有被删除表，因为现在从库停止在被删除之前的时间点
• 2.9 将所需表从server2复制到server1.

只有没有任何多表的UPDATE、DELETE或INSERT语句操作这个表时，上述流程才是可行的。任何这样的多表操作语句在被记录的时候，可能时基于多个数据库的状态，而不仅仅时当前要恢复的这个数据库，所以这样恢复出来的数据可能和原始的有所不同。(只有在使用基于语句的二进制日志时才会有这个问题;如果使用的是基于行的日志，重放过程不会碰到这个问题)

InnoDB崩溃恢复

InnoDB在每次启动时都会检测数据和日志文件，以确认是否需要执行恢复过程。而且InnoDB的恢复过程与前面的讨论不是一回事。它并不是恢复备份的数据;而是根据日志文件将事务应用到数据文件，将未提交的变更从数据文件中回滚。精确地描述InnoDB如何进行恢复工作，这有点太过复杂。我们要关注的焦点是当InnoDB有严重问题时如何实际执行恢复。大部分情况下InnoDB可以很好地解决问题。除非MySQL有Bug或硬件问题，否则不需要做任何非常规的事情，哪怕时服务器意外地断电。InnoDB会在启动时执行正常的恢复，然后一切就正常了，在日志文件中，可以看到如下信息。

InnoDB Doing recovery :scanned up to log sequence number 0 40817239
InnoDB: Starting an apply batch of log records to the database...

InnoDB会在日志文件中输出恢复进度的百分比信息。有些人说直到整个过程完成才能看到这些信息。耐心点，这个恢复过程是急不来的。如果心急而杀掉进程并重启，只会导致需要更长的恢复事件。如果服务器硬件有严重问题，例如内存或磁盘损坏，或遇到了MySQL或InnoDB的Bug，可能就不得不介入，这是要么进行强制恢复，要么阻止正常恢复发生。

InnoDB损坏的原因

InnoDB非常健壮且可靠，并且有许多的内建安全检测来防止、检测和修复损坏的数据——比其他MySQL存储引擎要强很多。然而,InnoDB并不能保护自己避免一切错误。最起码，InnoDB依赖于无缓存的IO调用和fsync()调用，直到数据完全地写入到物理介质上才会返回。如果硬件不能保证写入的持久化，InnoDB也就不能保证数据的持久，崩溃就有可能导致数据损坏。很多InnoDB损坏问题都是与硬件有关的(例如，因电力问题或内存损坏而导致损坏页的写入)。然而，在过往的经验中，错误配置的硬件是更多的问题之源。常见的错误配置包括打开了不包含电池备份电源的RAID卡的回写缓存，或打开了硬盘驱动器本身的回写缓存。这些错误将会导致控制器或驱动器"撒谎"，在数据实际上只写入到回写缓存上而不是磁盘上时，却说fsync()已经完成。换句话说，硬件没有提供保持InnoDB数据安全的保证。有时候及其默认就会这样配置，因为这样做可以得到更好的性能——对于某些场景确实很好，但是对事务数据服务来说却是个大问题。如果在网络附加存储(NAS)上运行InnoDB，也可能会遇到损坏，因为对NAS设备来说完成fsync()只是意味着设备接收到了数据。如果InnoDB崩溃，数据是安全的，但如果是NAS设备崩溃就不一定了。严重的损坏会使InnoDB或MyISAM崩溃，而不那么严重的损坏则可能只是由于日志文件未真正同步到磁盘而丢掉了某些事务

如何恢复损坏的InnoDB数据

InnoDB损坏有三种主要类型，它们对数据恢复有着不同程度的要求.

• 1.二级索引损坏
  一般可以用OPTIMIZE TABLE来修复损坏的二级索引;此外，也可以用SELECT INTO OUTFILE，删除和重建表，然后LOAD DATA INFILE的方法。(也可以将表改为使用MyISAM再改回来)。这些过程都是通过构建一个新表重建受影响的索引，来修复损坏的索引数据
• 2.聚簇索引损坏
  如果是聚簇索引损坏，也许只能使用innodb_forece_recovery选项来导出表。有时导出过程会让InnoDB崩溃;如果出现这样的情况，或许需要跳过导致崩溃的损坏页以导出其他的记录.聚簇索引的损坏比二级索引要更难修复，因为它会影响数据行本身，但在多数场合下只需要修复受影响的表。
• 3.损坏系统结构
  系统结构包括InnoDB事务日志，表空间的撤销日志(undo log)区域和数据字典。这种损坏可能需要做整个数据库的导出和还原，因为InnoDB内部绝大部份的工作都可能受到影响

一般可以修复损坏的二级索引而不丢失数据。然而，另外两种情形经常会引起数据的丢失。如果已经有备份，那最好还是从备份中还原，而不是试着从损坏的文件里区提取数据。如果必须从损坏的文件里提取数据，那一般过程是先尝试让InnoDB运行起来，然后使用SELECT INTO OUTFILE导出数据。如果服务器已经崩溃，并且每次启动InnoDB都会崩溃，那么而可以配置InnoDB停止常规恢复和后台进程的运行。这样也许可以启动服务器，然后在缺少或不做完整性检查的情况下做逻辑备份。innodb_forece_recovery参数控制着InnoDB在启动和常规操作时要做哪一种类型的操作。通常情况下这个值是0，可以增大到6.MySQL使用手册里记录了每个数值究竟会产生什么行为；再次我们不会重复这段信息，但是要告诉你:在有点危险的前提下，可以把这个数值调高到4.使用这个设置时，若有数据页损坏，将会丢失一些数据;如果将数值设得更高，可能会从损坏的页里提取到坏掉的数据。或者增加执行SELECT INTO OUTFILE时崩溃的风险。换句话说，这个值直到4都对数据没有损害，但可能丧失修复问题的机会，而到5和6会更主动地修复问题，但损害数据的风险也会很大。当把innodb_force_recovery设为大于0的某个值时，InnoDB基本上是只读的，但是仍然可以创建和删除表。这可以阻止进一步的损坏，InnoDB会放松一些常规检查,以便在发现坏数据时不会特意崩溃。在常规操作中，这样做是由安全保障的。但是在恢复时，最好还是避免这样做。如果需要执行InnoDB强制恢复，有个好主意是配置MySQL使它在操作完成之前不接受常规的连接请求。
如果InnoDB的数据损坏到了根本不能启动MySQL的程度，还可以使用Percona出品的InnoDB Recovery Toolkit从表空间的数据文件里直接抽取数据。Percona Server还有允许服务器在某些表损坏时仍能运行的选项，而不是像MySQL那样在单个表损坏页被检测出时就默认强制崩溃