为什么 MySQL 存储引擎在一种情况下在恢复时发生变化？

Question

在我的生产数据库生活中，发生过一次悲剧，在恢复最近的备份时，MySQL 引擎类型从 InnoDB 意外更改为 MyISAM。结果是所有参照完整性都丢失了。

是什么导致了这一事件？我的生产数据库是 MySQL Server 5.1。

Answer 1

这让我想起了我做过十几次的事情（幸运的是小数据集小于 10GB）。将 mysqldump 恢复到新服务器时，您必须绝对确保新服务器上的 InnoDB 设置与 InnoDB 设置相同。

对于您选择将 mysqldump 还原到的新服务器，请运行以下命令：

SHOW ENGINES;

这将显示 MySQL 实例中可用的所有存储引擎。以下是来自运行 MySQL 5.5.9 的服务器的示例：

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

请注意，InnoDB 在 Support 列中有 DEFAULT。Support 列有四个可能的值：

• 是的
• 不
• 默认
• 残疾人士

有一天，我正在恢复的一台服务器的 innodb_buffer_pool_size 配置不匹配。因为我设置了 innodb_buffer_pool_size=512G 而不是 512M（明显的错字），InnoDB 会出现 DISABLED。将数据加载到新服务器时，每个 CREATE TABLE 在执行时默认为 MyISAM。我没有注意到任何事情，直到我看到数十个数据库连接等待写入同一个表，这是针对 MyISAM 的大量写入的典型情况。解决方案只是使用正确的 InnoDB 设置重新开始并重新加载。

故事的道德启示

1. 始终确保您可以将数据恢复到与 /etc/my.cnf 中指定的配置相同的配置。如果新服务器的磁盘空间和/或 RAM 比您 mysqldump 的服务器少，他们会小心地将 /etc/my.cnf 配置为对您要恢复到的新服务器最有意义的最大设置。
2. 始终运行显示引擎；确保每个存储引擎都在运行。
3. 始终阅读错误日志并验证与启动、InnoDB 崩溃恢复、全文停用词列表声明、MyISAM 修复选项、缓冲区和数据库连接请求的内存量有关的任何异常。
4. 始终确保 ib_logfile0 和 ib_logfile1 的大小与旧服务器的 /etc/my.cnf 中指定的大小相同。
5. 始终使用开发和暂存数据库服务器来加载旧备份并测试可用性。