主备数据库与多主数据库的拓扑比较

主备数据库与多主数据库的拓扑比较

下面，我将以单个站点和多个站点的，主-备和多主模式为例，和您讨论数据库的各种部署类型，它们各自的特点和在功效上的利弊，以便您能够设计出具有高可用性和业务弹性的数据库架构。

首先让我们来看在单个站点上的数据库部署类型：

单节点

单个站点上的单节点部署

最基本的部署方式当属单个站点上的单节点架构。在业务连续性方面，这显然是最不具备优势的部署模式。由于无法提供高可用性，其唯一的DR(灾难恢复)机制只能通过现有的备份文件，去恢复数据库。可见，这种类型的部署，通常出现在不太重要的环境中。例如，在CI/CD管道的技术中，自动化测试已经成为了该过程的一部分，那么在开发或使用过程中，我们就可以将诸如：CockroachDB、***、以及SQL Server等几乎所有数据库，都按照这种方式进行部署。

单节点部署模式的好处是：

由于只有一个节点需要获得数据库的许可证，因此它具有一定的成本效益。但是，如果在真实的生产中采用此模式，那么由于业务中断所带来的损失，以及引发的补救成本，则可能是一个天文数字。

单节点部署模式的缺点是：

缺乏HA(高可用性)。如果唯一的节点出现错误或问题，则无法实现故障的转移。因此，您必须手动修复现有的失败节点，然后再从备份中进行数据恢复。任何可能导致停机的维护，都必须事先考虑到如何转移数据流的传输;而任何对于系统的修补或升级，也都会以某种形式给客户或服务造成影响。

多节点

我们再来看单个站点上的多节点架构。显然，在技术实现上，它会对DR和HA有所改进。在此类部署中，我们一般可以选用主-被模式、或多主模式，并配置出2个或更多的节点。而且，这些节点通常可以分布在不同的故障域中，例如：某个机架、某组网络交换机或磁盘。

主-被模式

主-被

这种模式通常是由一个主节点和n个被节点组成。这意味着，如果主节点出现了问题，应用程序可以立即指向被节点，并将被节点提升为主节点。该过程往往是自动完成的。不过，由于应用程序在重新指向新的节点时需要切换时间，因此服务有可能会出现中断。可见，该模式虽然优于单节点的架构，但是仍非生产环境的完美部署方案。可以被配置主-被模式的数据库包括：***、SQL Server、MySQL、以及Postgres。

主-被模式的优点是：

在您签署了主数据库支持协议后，某些数据库提供商会允许您免费地将其运行在被节点上，因此该模式仍然具有一定的成本效益。相比单节点架构，该模式提供了更好的HA能力。

主-被模式的缺点是：

既然增加了被节点，那么它必然需要跑在相应的硬件、或虚拟资源上，那么您将不得不为此支付额外的费用。而且，它们只会在发生灾难或故障时，才会被用到。由于在发生故障时，所有服务器都需要重新同步，才能统一为主-被配置，因此其运维的成本较高。

多主模式

单个站点上的多活模式

在这个模式中，集群中的所有节点，都可以同时进行读写操作。由于在多个活动的集群中，所有节点都是平等的，因此它们没有了所谓主节点和被节点的概念。据此，您不但拥有可控的HA和DR功能，而且还具有可以轻松扩展的固有能力。目前，可以被部署为此类模式的数据库包括：CockroachDB、***以及Couchbase。

多主模式的优点是：

无论是读取还是写入操作，都具有可扩展性。其高可用性体现在系统执行升级和修补等维护任务时，不会产生任何停机。由于所有节点一直都处于活跃且被使用的状态，因此它们在资源利用率方面具有较高的成本效益。虽然由此会产生更高的预购许可证的相关成本，但是该方案在市场上最具有成本效益。可以达到RPO(恢复数据点目标)为 0，而RTO(恢复时间目标)<10秒。

多主模式的缺点是：

由于会导致网络流量的翻倍增加，因此该解决方案往往会影响到系统的整体性能。不过，这对于单个站点而言影响甚微，毕竟其网络速度非常快，带宽也很大。诸如***之类的技术往往需要定期的维护工作。也就是说，在完成了恢复操作之后，应复查并确保所有节点上的数据，被已完成复制、且保持一致。

总体而言，在单个站点上进行数据库部署的总体缺点在于，它无法应对整个站点或区域的中断情况。对此，我们往往需要用到下面将要讨论到的多个站点部署的模式。

多个站点上的多活模式

多站点模式主要体现在不同的节点分布在不同的站点或区域中。如果我们需要通过在线状态监测的方式，及时发现掉线的站点或区域，那么该部署模式则非常适合。也就是说，与单个站点的部署相比，多个站点部署的最大优势在于，您可以在某个或某几个区域性数据中心、或站点出现中断时，仍然可以提供原有的数据服务。

如前所述，在单个站点中，多主与主-被模式有着许多相似的优缺点。但是，对于多个站点而言，我们应当更多地考虑以下两个方面：

当然，您可以根据应用的实际需求，选用其他更为可靠的解决方案。

小结

正如我们在上述每一种部署方案的优缺点中所介绍的那样，无论您选择的哪一种解决方案，都需要考虑和满足应用业务的连续性(如HA和DR)、总体拥有成本(完整的TCO，不仅包括前期的构建支出，还包含了运维与中断所产生的成本)、以及性能上的综合需求。

原文标题：Active-Passive vs Multi-Active Database Topologies，作者：Daniel Holt

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。