这个问题我遇到过两三次。我的一位客户恢复了备份，但意外地修改了引擎设置。结果，所有外键约束都丢失了，应用程序开始显示奇怪的结果。
第二个事件发生在我们的现场生产服务器上。 MySQL 停止支持 InnoDB 并显示错误“Unsupported Engine Type”。
我在 Google 上进行了搜索，发现了很多类似的查询。我想知道 MySQL 是否会修复这个错误。现在是转向 PostgreSQL 的合适时机吗？为什么我仍然坚持使用 MySQL 是因为它广泛的用户群。我对 PostgreSQL 了解不多。
谁能建议解决这个 MySQL 问题的方法或替代方法？
最佳答案
这听起来像是一个明确的迹象，表明从备份恢复没有经过适当的测试，这显然需要完成。
也就是说，这不是我第一次听说这种情况，有时结果会比这更糟糕。不幸的是，据我所知，如果 MySQL 无法满足请求，它并不是真正阻止 MySQL“降级”您的表引擎的方法。因此，您只需要小心并检查恢复结果即可。实际上，您应该始终这样做。
这是 MySQL 在很多情况下的运行方式(静默更改表管理器，忽略外键而不是在使用错误的表管理器时抛出“不支持的功能”错误等)，并且它不被视为错误。因此，如果您确实认为这是一个您不想忍受的错误，那么是的，可能值得考虑切换数据库。
现在，关于实际问题的提示:我已经看到许多站点只是在他们的监控中部署一个检查(例如 nagios)来验证所有表都是 InnoDB，如果不是的话'我会在通用监控系统中发出严重警报。在您将错误数据输入系统之前，类似的东西很可能已经为您发现了这个问题。它远非完美，但它让您有机会及早发现问题。
关于mysql - 如何处理意外的 MySQL 数据库引擎更改？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1965603/