如何处理意外的MySQL数据库引擎更改？

Question

我遇到这个问题两到三次。我的一位客户恢复了备份，但它意外地修改了引擎设置。结果，所有外键约束都丢失了，应用程序开始显示出奇怪的结果。

第二起事件发生在我们的实时制作服务器上。 MySQL停止支持InnoDB并显示错误，“不支持的引擎类型”。

我搜索了Google并发现了许多类似的查询。我想知道MySQL是否会修复这个bug。是否适合转向PostgreSQL？为什么我仍然坚持使用MySQL是因为它拥有广泛的用户群。我对PostgreSQL了解不多。

有人可以建议处理这个MySQL问题的方法吗？

Answer 1

这听起来像是一个明确的迹象表明备份的恢复没有得到适当的测试，显然需要这样做。

那就是说，这不是我第一次听说过这种情况，有时结果比这更糟糕。不幸的是，如果AFAIK无法满足请求，那么AFAIK就不能真正阻止MySQL“降级”你的表引擎。因此，您只需要小心并检查还原的结果。真的，你应该一直这样做。

这是MySQL在很多情况下运行的方式（默默地更改表管理器，忽略外键而不是在使用错误的表管理器时抛出“不支持的功能”错误），并且它不被视为错误。因此，如果您确实认为这是一个您不想忍受的错误，那么可能值得查看切换数据库。

现在，关于实际问题的提示：我已经看到许多网站只是在他们的监控（例如nagios）中部署了一个检查来验证所有表都是InnoDB，如果它们不是它'将在一般监控系统中发出严重警报。在您将错误的数据输入系统之前，类似的东西很可能已经找到了这个问题。它远非完美，但它让你有机会更早地解决问题。

Answer 2

这种操作无能的气味。

您应该管理您的服务器版本，以便它只能恢复到定义良好的可重现服务器版本，而不会有错误配置或不适当版本的mysql。这是管理应用程序的唯一方法。

我与您的运营团队或运营经理谈谈。

你绝对不应该切换到另一个数据库，因为你的运营团队出错了。

Answer 3

可以使用一堆不同的SQL Modes来配置MySQL，这些{{3}}可以控制不正确查询的静默和允许。

根据我的经验，大多数发行版中的默认配置太过宽松了。

您可能希望在注销MySQL之前更改这些配置选项，因为它不够强大的DBMS。

将其设置为更严格的模式，您可能会在恢复备份转储时开始发现错误，从而为您提供有关错误的线索。