【MySQL精通之路】InnoDB(18)-备份与恢复

1.InnoDB备份

1.1 热备份

1.2 冷备份

1.3 使用mysqldump的逻辑备份

2.InnoDB恢复

2.1 实时恢复

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

2.3 InnoDB崩溃恢复

2.3.1 表空间发现

2.3.2 Redolog应用程序

2.3.3 未完成交易的回滚

2.3.4 更改缓冲区合并

2.3.5 清除

2.4 故障恢复期间的表空间发现

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

有关适用于InnoDB的备份技术的信息，请参阅“InnoDB备份”。

有关时间点恢复、磁盘故障或损坏的恢复以及InnoDB如何执行崩溃恢复的信息，请参阅“InnoDB恢复”

1.InnoDB备份

安全数据库管理的关键是定期备份。

根据您的数据量、MySQL服务器数量和数据库工作负载，您可以单独或组合使用这些备份技术：热备份与MySQL Enterprise backup；

MySQL服务器关闭时通过复制文件进行冷备份；

使用mysqldump进行逻辑备份，用于较小的数据卷或记录数据库对象的结构信息。

热备份和冷备份是复制实际数据文件的物理备份，mysql直接使用这些文件进行快速恢复。

推荐使用MySQL Enterprise Backup备份工具进行数据备份。

笔记
InnoDB不支持使用第三方备份工具恢复的数据库。

1.1 热备份

mysqlbackup命令是MySQL Enterprise Backup组件的一部分，它允许您备份正在运行的MySQL实例，包括InnoDB表，在生成数据库的一致快照的同时，对操作的干扰最小。

当mysqlbackup复制InnoDB表时，对InnoDB表的读写可以继续。

MySQL Enterprise Backup还可以创建压缩备份文件，并备份表和数据库的子集。

结合MySQL的Binlog，用户可以执行实时恢复。

MySQL Enterprise Backup是MySQL Enterprise订阅的一部分。

有关更多详细信息，请参阅“MySQL企业备份概述”。

MySQL Enterprise Backup为MySQL数据库执行热备份操作。该产品是为InnoDB存储引擎创建的表的高效可靠备份而设计的。为了完整起见，它还可以备份MyISAM和其他存储引擎中的表。
以下讨论简要总结了MySQL企业备份。有关更多信息，请参阅MySQL Enterprise Backup手册，可在https://dev.mysql.com/doc/mysql-enterprise-backup/en/.
热备份是在数据库运行和应用程序对其进行读写时执行的。这种类型的备份不会阻止正常的数据库操作，甚至可以捕获备份时发生的更改。出于这些原因，当您的数据库“增长”时，热备份是可取的——当数据足够大，备份需要大量时间，当数据对您的业务足够重要，您必须捕获最后的每一次更改，而不会使您的应用程序、网站或web服务离线。
MySQL Enterprise Backup对所有使用InnoDB存储引擎的表进行热备份。对于使用MyISAM或其他非InnoDB存储引擎的表，它会进行“热”备份，数据库会继续运行，但在备份时无法修改这些表。为了高效的备份操作，您可以将InnoDB指定为新表的默认存储引擎，或者将现有表转换为使用InnoDB存储引擎。

1.2 冷备份

如果你可以关闭MySQL服务器，你可以制作一个物理备份，该备份由InnoDB用来管理其表的所有文件组成。使用以下步骤：

1.慢关闭MySQL服务器，并确保其停止时没有错误。

2.将所有InnoDB数据文件（ibdata文件和.ibd文件）复制到一个安全的地方。

3.将所有InnoDB重做日志文件（MySQL 8.0.30及更高版本中的#ib_redoXX文件或早期版本中的ib_logfile文件）复制到安全的地方。

4.将您的my.cnf配置文件复制到安全的地方。

1.3 使用mysqldump的逻辑备份

除了物理备份之外，建议您通过使用mysqldump转储表来定期创建逻辑备份。

二进制文件可能在您没有注意到的情况下被损坏。转储的表存储在可读的文本文件中，因此察觉表损坏变得更容易。

此外，由于格式更简单，发生严重数据损坏的可能性更小。

mysqldump还有一个--singletransaction选项，用于在不锁定其他客户端的情况下生成一致的快照。

请参阅“建立备份策略”。

复制与InnoDB表一起工作，因此您可以使用MySQL复制功能在需要高可用性的数据库站点上保留数据库的副本。

请参阅“InnoDB和MySQL主从复制”。

2.InnoDB恢复

2.1 实时恢复

要将InnoDB数据库从物理备份的时候恢复到现在，您必须在启用二进制日志记录的情况下运行MySQL服务器，甚至在进行备份之前也是如此。

要在恢复备份后实现实时恢复，可以应用备份后二进制日志中的更改。

请参阅“实时（增量）恢复”。

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

如果数据库损坏或发生磁盘故障，则必须使用备份执行恢复。

如果发生损坏，请首先查找未损坏的备份。

恢复基本备份后，使用mysqlbinlog和mysql从二进制日志文件中进行实时恢复，以恢复备份后发生的更改。

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

在某些情况下，明显的数据库页面损坏实际上是由于操作系统损坏了自己的文件缓存，磁盘上的数据。最好先尝试重新启动计算机。这样做可以消除看起来是数据库页面损坏的错误。

如果MySQL仍然因为InnoDB一致性问题而无法启动，

请参阅“强制InnoDB恢复”

了解在恢复模式下启动实例的步骤，这允许您转储数据。

2.3 InnoDB崩溃恢复

要从MySQL服务器意外关闭中恢复，唯一的要求就是重新启动MySQL服务器。

InnoDB会自动检查日志，并将数据回滚到当前位置。InnoDB会自动回滚崩溃时存在的未提交事务。

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

2.3.1 表空间发现

表空间发现是InnoDB用来识别需要redolog应用程序的表空间的程序。

请参阅下文故障恢复期间的表空间发现。

2.3.2 Redolog应用程序

Redolog应用程序在初始化期间执行，然后再接受任何连接。

如果在关闭或崩溃时将所有更改从缓冲池刷新到表空间（ibdata*和*.ibd文件），则会跳过Redolog应用程序。

如果启动时缺少重做日志文件，InnoDB也会跳过重做日志应用程序。

每次记录更改时，都会将当前最大自动增量计数器数值写入重做日志，这使其能够安全崩溃。

在恢复过程中，InnoDB扫描Redolog日志以收集计数器值的更改，并将这些更改应用于内存中的表对象。

有关InnoDB如何处理自动增量值的更多信息，请参阅

InnoDB中的AUTO_INCREMENT处理：

InnoDB auto_increment计数器初始化：

当遇到索引树损坏时，InnoDB会向Redolog中写入损坏标志，这使得损坏标志可以安全崩溃。

InnoDB还将内存中的损坏标志数据写入每个检查点上的存储引擎专用系统表。

在恢复过程中，InnoDB从两个位置读取损坏标志并合并结果，然后将内存表和索引对象标记为损坏。