我有一个带有MyISAM表的AWS RDS MySQL 5.7数据库，我希望将其迁移到自定义VPC中的另一个RDS，迁移后，将这些MyISAM表转换为InnoDB。 如果我说得不错，创建正确自动备份的唯一方法是使用此处说明的以下过程：“使用不支持的MySQL存储引擎进行自动备份” https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#Overview.BackupDeviceRestrictions
之前有人做过这个程序吗？ 如果每晚都从当前的RDS DBInstance成功创建快照，即使它包含MyISAM表，该怎么办？
谢谢！
答案 0 :(得分：5)
问题不在于快照创建。当你真正尝试使用其中一个快照时，这可能会出错。
RDS快照通过捕获快照来工作，如果您的RDS实例的基础EBS卷（您无法看到此卷，但它就在那里 - RDS在EC2上运行，具有“隐藏”实例和卷）。
EBS快照捕获硬盘驱动器的全部内容，与快照过程开始时恰好存在的内容完全相同。
如果你执行了sudo killall -9 mysqld，快照上的内容与MySQL服务器上的内容基本相同 - 就好像服务器立即停止了所有内容而没有执行任何操作它通常会清理以便正常关闭。使用RDS，事情并不那么引人注目，因为RDS确实采取了一些预防措施，但从根本上说，这就是发生的事情的本质。
当您从快照创建RDS实例时，实例启动时发生的第一件事就是您重新启动已终止的MySQL服务器守护程序时假设服务器将执行的操作：InnoDB崩溃恢复。
InnoDB崩溃恢复
要从MySQL服务器崩溃中恢复，唯一的要求是重启MySQL服务器。 InnoDB自动检查日志并执行数据库前滚到现在。 InnoDB会自动回滚崩溃时出现的未提交的事务。
https://dev.mysql.com/doc/refman/5.7/en/innodb-recovery.html#innodb-crash-recovery
崩溃恢复是InnoDB的机制，可以使内部数据结构中的所有内容恢复原状，并确保所有数据完好无损，就像应用程序离开时一样。这是可能的，因为InnoDB是一个事务存储引擎。这意味着很多不同的东西，但在这种情况下它具体意味着InnoDB不仅仅是在更改表时更改表数据。它经历了一个可以简化的过程：
这意味着，在更改完成之前，InnoDB可以被中断，并且随后可以从中断处继续，而不会破坏或丢失数据。
MyISAM没有这样的机制。它只是直接写入数据文件。即使没有主动使用MyISAM表，它仍可能需要在服务器启动时进行修复，以清理其结构。在某些情况下，修复表是不可能的，表中的全部或部分数据都将丢失。
如果在快照发生时刷新并锁定了MyISAM表，它们在磁盘上处于静止状态，就好像服务器在快照发生之前已经正常关闭一样，因此它们在快照上会保持稳定
但是快照过程似乎总是会成功，因为快照只是复制磁盘上的任何内容，就像快照正在进行时一样。
问题在于捕获的快照可能无法使用，并且您无法知道快照是否完全可行。
¹请注意，第一步“将建议的更改存储到磁盘”与系统变量innodb_flush_log_at_trx_commit相关，如果设置为1，系统变量会使系统变慢，但也是最安全的设置，因为在第一步完成之前，您的查询实际上不会成功。 2的设置仍然相当安全，因为它仍然会写入更改，但不会要求操作系统确认它们在查询返回成功之前确实已经写入硬盘驱动器...但是在崩溃中，您的申请认为已经承诺的交易可能会或可能不会幸免。