哪些数据库服务器不会因服务器重启而中断?(集群?)

哪些数据库服务器不会因服务器重启而中断?(集群?)

我们被要求提供一个系统,让中央数据库服务器继续运行,即使对服务器操作系统或数据库服务器软件应用安全更新也是如此。据我所知,这包括需要重新启动服务器的安全更新。

集群技术似乎很明显,但如果服务器真的可以在集群使用时重新启动,我有几个问题:

  • 哪些数据库产品可以做到这一点?
  • 它是如何工作的?它会同时将数据库数据存储在所有服务器上吗?还是在一台服务器重新启动时将任务转移到另一台服务器?
  • 它如何影响性能,尤其是查询延迟?

答案1

完全无中断在定期维护(包括重新启动操作系统)期间?Oracle RAC。这是我能想到的唯一真正选择,当然也是我唯一信任的并行集群数据库。即使 RAC 有时也必须关闭以安装数据库补丁,但大多数补丁可以在运行时应用。

如果您可以处理至少 10-15 秒的停机时间,那么还有许多其他选项,包括应用程序级别的群集(veritas 群集、microsoft 群集、oracle 群集件)或数据库级别的复制。虚拟基础设施本身不会有太大帮助。操作系统仍然必须停机。

还可以将复制的数据库与多宿主客户端结合起来,以实现不间断的生产,尽管目前我不记得任何此类客户端的名称。

我可能还想补充一点,您可能希望使用某种 *NIX 来将重启次数降至最低。据我所知,过去几年中,RHEL 和 OEL 上只有一次更新值得重启。

Oracle RAC 是一个并行集群。数据库存储在共享存储中,并由所有节点同时访问。如果操作正确,在大多数情况下,它应该可以提高整体性能,并且查询响应时间几乎没有差异。然而,这是一项复杂的技术,正确操作绝非易事。

还有一些其他并行技术承诺五个九(99,999%的正常运行时间,相当于每年 5 分钟的停机时间),但它们要么太旧(VAX),要么太新(NDB)。

答案2

可靠系统与不可靠系统之间的区别零停机时间将铝制气球送入低地球轨道与将人类送上月球并安全返回之间的区别。

我会研究一下传统方法来实现这一点,在我看来,如果您需要它第一次就成功并且不超出预算,那么您应该研究这些方法。

旧的备用方案是 OpenVMS 集群和 Tandem(现在为 HP)NonStop。它们都是为运行完全相同的数据库和相同代码的多台计算机而设计的。它们都旨在通过操作系统和软件升级和补丁提供 100% 的正常运行时间。它们都有经过验证的、数十年的正常运行记录。

现在——理论上,现代的东西可以提供这种服务。在实践中,你会遇到这样的问题:“哎呀,我们的许可证服务器出现错误,您的虚拟机现在无法启动“十年后,我相信这些技术将经过测试并被证明是可靠的,但在此之前,如果你需要它发挥作用,请对你所相信的故事非常谨慎。

最后,要使系统如此可靠,最重要的是设计好、构建好,并且好好照顾它因为在实践中,等式中最不可靠的就是键盘后面的人。

答案3

MySQL 集群http://www.mysql.com/products/database/cluster/

  • 无共享架构(中央存储是不是必需的)。
  • 滚动升级——无需停止集群即可更新。
  • 您可以指定集群中应存在多少个数据副本。
  • 历史上它一直是一个内存数据库,这意味着你的总数据库不能超过集群中的 RAM 数量(减去复制的开销)。
  • 现在也支持磁盘数据库。
  • 没有全部其他一些 MySQL 存储引擎的特性。

答案4

我相信唯一的办法就是使用聚类您需要将多个 DB 服务器组合成一个集群。然后一个服务器可以自动接管另一个发生故障的服务器。这称为“故障转移”(或高可用性集群)。

回答您的问题:

哪些数据库产品可以做到这一点?

所有这些都宣传“集群支持”。我知道至少 MySQL 和 Oracle 支持,但许多其他 DBMS 可能也支持它。

它是如何工作的?它会同时将数据库数据存储在所有服务器上吗?还是在一台服务器重新启动时将任务转移到另一台服务器?

两者都有。服务器会定期同步数据,因此所有服务器都会保存数据。至于哪个服务器实际响应请求,有两种选择:在负载平衡集群中,所有服务器共享负载(因此您可以获得更好的性能);在高可用性集群中,通常由一台计算机完成工作,如果备用计算机发生故障,则由备用计算机接管(故障转移)。

它如何影响性能,尤其是查询延迟?

抱歉,我没有这方面的经验。通常情况下,开销应该很小,但故障转移可能需要一些时间并导致超时。

相关内容