我们被要求提供一个中央数据库服务器继续运行的系统，即使在对服务器的操作系统或数据库服务器软件应用安全更新时也是如此。据我所知，这包括需要重新启动服务器的安全更新。
集群技术似乎很明显，但如果服务器真的可以在集群使用时重新启动，我有几个问题：
可靠系统与零停机时间的区别在于，将铝制气球放入近地轨道与将人送上月球并安全返回之间的区别。
我会看看这样做的老派方法，在我看来，如果您需要它第一次工作并且不超出预算，您应该考虑这些方法。
旧的备用数据库是 OpenVMS 集群和 Tandem（现在是 HP）NonStop。这两者都是为运行完全相同的数据库和相同代码的多台计算机设计的。两者都旨在通过操作系统和软件升级和补丁提供 100% 的正常运行时间。两者都有经过验证的、长达数十年的正常工作记录。
现在 - 有一些现代的东西可以在纸上提供这一点。在实践中，您会遇到诸如“哎呀，我们在我们的许可证服务器中犯了一个错误，您的虚拟机现在无法启动”之类的问题。十年后，我相信这些技术将经过测试并被证明是可靠的，但在那之前，如果您需要它发挥作用，请在您相信的故事中非常保守。
最后，要使系统如此可靠，最重要的是设计好、构建好、维护好，因为在实践中，等式中最不可靠的是键盘后面的人。
MySQL 集群http://www.mysql.com/products/database/cluster/
在计划维护期间完全没有中断，包括重新启动操作系统？甲骨文RAC。这是我能想到的唯一真正的选择，当然也是我对此信任的唯一并行集群数据库。即使 RAC 有时也必须停机以获取数据库补丁，但大多数都可以在运行时应用。
如果您可以处理至少 10-15 秒的停机时间，还有许多其他选项，包括应用程序级别的集群（veritas 集群、microsoft 集群、oracle clusterware）或数据库级别的复制。虚拟基础设施本身并没有多大帮助。操作系统仍然需要关闭。
还可以将复制数据库与多宿主客户端结合起来以实现不间断的生产，尽管我目前不记得任何此类客户端的名称。
我可能会补充一点，您可能想要使用某种 *NIX 来将它们的重新启动次数降至最低。据我所知，过去几年 RHEL 和 OEL 上只有一次值得重新启动的更新。
Oracle RAC 是一个并行集群。数据库存储在共享存储上，并由所有节点同时访问。如果做得正确，在大多数情况下应该可以提高整体性能，并且查询响应时间几乎没有差异。然而，这是一项复杂的技术，正确实施绝非易事。
还有一些其他并行技术承诺五个九（99,999% 的正常运行时间，相当于每年 5 分钟的停机时间），但它们要么太旧 (VAX)，要么太新 (NDB)。