参考官方文档：
https://dev.mysql.com/doc/refman/5.7/en/innodb-backup-recovery.html


本节介绍与InnoDB备份和恢复相关的主题。




14.18.1 InnoDB 备份


安全数据库管理的关键是定期备份。 根据您的数据量，MySQL服务器数量和数据库工作负载，您可以单独或组合使用这些备份技术：使用MySQL Enterprise Backup进行热备份; 在MySQL服务器关闭时通过复制文件进行冷备份; 使用mysqldump进行逻辑备份以用于较小的数据卷或记录方案对象的结构。 冷热备份是复制实际数据文件的物理备份，mysqld服务器可以直接使用它来加快恢复速度。




热备份


要么使用MYSQL 企业版的 mysqlbackup工具，要么使用开源的备份工具xbackup。



冷备份


如果可以关闭MySQL服务器，则可以进行物理备份，该备份由InnoDB用于管理其表的所有文件组成。 使用以下过程：

• 执行MySQL服务器的慢速关闭，并确保它停止没有错误。
• 将所有InnoDB数据文件（ibdata文件和.ibd文件）复制到一个安全的地方。
• 将InnoDB表的所有.frm文件复制到安全的位置。
• 将所有InnoDB日志文件（ib_logfile文件）复制到安全位置。
• 将my.cnf配置文件复制到安全的地方。

使用 mysqldump 进行逻辑备份


除物理备份外，建议您通过使用mysqldump转储表来定期创建逻辑备份。 如您可能没注意到，二进制文件已损坏。 转储表存储在人类可读的文本文件中，因此定位表损坏变得更容易。 此外，由于格式更简单，严重数据损坏的可能性更小。 mysqldump还有一个--single-transaction选项，用于在不锁定其他客户端的情况下创建一致的快照。 请参见第7.3.1节“建立备份策略”。


复制适用于InnoDB表，因此您可以使用MySQL复制功能将数据库副本保存在需要高可用性的数据库站点。 请参见第14.19节“InnoDB和MySQL复制”。


14.18.2 InnoDB 恢复




时间点的恢复


要从进行物理备份时恢复InnoDB数据库，您必须在启用二进制日志记录的情况下运行MySQL服务器，甚至在进行备份之前。 要在还原备份后实现时间点恢复，您可以应用备份后发生的二进制日志中的更改。


从数据损坏或磁盘故障中恢复


如果数据库损坏或发生磁盘故障，则必须使用备份执行恢复。 在损坏的情况下，首先找到未损坏的备份。 还原基本备份后，使用mysqlbinlog和mysql从二进制日志文件执行时间点恢复，以还原备份后发生的更改。




在某些数据库损坏的情况下，转储，删除和重新创建一个或几个损坏的表就足够了。 您可以使用CHECK TABLE语句检查表是否已损坏，尽管CHECK TABLE自然无法检测到所有可能的损坏类型。




在某些情况下，明显的数据库页面损坏实际上是由于操作系统破坏了自己的文件缓存，磁盘上的数据可能没问题。 最好先尝试重新启动计算机。 这样做可能会消除似乎是数据库页面损坏的错误。 如果MySQL由于InnoDB一致性问题仍然无法启动，请参见第14.21.2节“强制InnoDB恢复”，了解在恢复模式下启动实例的步骤，该模式允许您转储数据。




InnoDB 崩溃 恢复


要从MySQL服务器崩溃中恢复，唯一的要求是重启MySQL服务器。 InnoDB自动检查日志并执行数据库前滚到现在。 InnoDB会自动回滚崩溃时出现的未提交的事务。 在恢复期间，mysqld显示类似于此的输出：


InnoDB: Log scan progressed past the checkpoint lsn 369163704
InnoDB: Doing recovery: scanned up to log sequence number 374340608
InnoDB: Doing recovery: scanned up to log sequence number 379583488
InnoDB: Doing recovery: scanned up to log sequence number 384826368
InnoDB: Doing recovery: scanned up to log sequence number 390069248


InnoDB崩溃恢复包括几个步骤：

• 表空间发现

表空间发现是InnoDB用于识别需要重做日志应用程序的表空间的过程。

• redo log 应用程序
  
  在接受任何连接之前，在初始化期间执行重做日志应用程序。 如果在关闭或崩溃时将所有更改从缓冲池刷新到表空间（ibdata *和* .ibd文件），则会跳过重做日志应用程序。 如果在启动时缺少重做日志文件，InnoDB也会跳过重做日志应用程序。
  
  
  即使可以接受某些数据丢失，也不建议删除重做日志以加快恢复。 只有在干净关闭后才能考虑删除重做日志，并将innodb_fast_shutdown设置为0或1。
  
  
  
• 不完全事务的回滚

不完整的事务是在崩溃或快速关闭时处于活动状态的任何事务。 回滚未完成事务所花费的时间可以是事务在中断之前处于活动状态的时间量的三倍或四倍，具体取决于服务器负载。

您无法取消正在回滚的事务。 在极端情况下，当回滚事务预计需要特别长的时间时，使用innodb_force_recovery设置为3或更高时启动InnoDB可能会更快。

• 变更 buffer 合并

将更改缓冲区（系统表空间的一部分）中的更改应用于二级索引的叶页，因为索引页将读取到缓冲池。

• purge

删除活动事务不再可见的删除标记记录。


重做日志应用程序之后的步骤不依赖于重做日志（除了用于记录写入），并且与正常处理并行执行。 其中，仅回滚未完成的事务对于崩溃恢复是特殊的。 插入缓冲区合并和清除在正常处理期间执行。


在重做日志应用程序之后，InnoDB会尽可能早地接受连接，以减少停机时间。 作为崩溃恢复的一部分，InnoDB会在服务器崩溃时回滚未提交的事务或处于XA PREPARE状态的事务。 回滚由后台线程执行，与新连接的事务并行执行。 在回滚操作完成之前，新连接可能会遇到与已恢复事务的锁定冲突。


在大多数情况下，即使MySQL服务器在重度活动过程中意外终止，恢复过程也会自动发生，并且不需要DBA执行任何操作。 如果硬件故障或严重的系统错误损坏了InnoDB数据，MySQL可能会拒绝启动。



在 崩溃恢复期间的表空间发现


如果在恢复期间，InnoDB遇到自上一个检查点以来写入的重做日志，则必须将重做日志应用于受影响的表空间。 在恢复期间标识受影响的表空间的过程称为表空间发现。


表空间发现是通过将重做日志从最后一个检查点扫描到用于修改表空间页面时写入的MLOG_FILE_NAME记录的日志末尾。 MLOG_FILE_NAME记录包含表空间空间ID和文件名。


在启动时，InnoDB打开系统表空间和重做日志。 如果自上一个检查点以来写入了重做日志记录，则会根据MLOG_FILE_NAME记录打开受影响的表空间文件。


为所有持久表空间类型编写MLOG_FILE_NAME记录，包括每表文件表空间，通用表空间，系统表空间和撤消日志表空间。


基于重做日志的发现具有以下特征：

• 仅访问自上次检查点以来修改的表空间* .ibd文件。
• 应用重做日志时，将忽略未附加到InnoDB实例的表空间* .ibd文件。
• 如果系统表空间的MLOG_FILE_NAME记录与影响系统表空间数据文件名的服务器配置不匹配，则在应用重做日志之前，恢复将失败并显示错误。
• 如果缺少日志扫描部分中引用的表空间文件，则拒绝启动。
• 如果日志中存在文件删除重做日志记录（MLOG_FILE_DELETE），则仅忽略丢失表空间* .ibd文件的重做日志。 例如，表重命名失败可能导致“缺少”* .ibd文件而没有MLOG_FILE_DELETE记录。 在这种情况下，您可以手动重命名表空间文件并重新启动崩溃恢复，也可以使用innodb_force_recovery选项以恢复模式重新启动服务器。 在恢复模式下启动服务器时，将忽略缺少的* .ibd文件。

MySQL 5.7中引入的基于重做日志的发现，取代了早期MySQL版本中使用的目录扫描，以构建应用重做日志所需的“空间ID到表空间文件名”映射。