在现代数据管理中，企业对于可靠性、可用性和成本的平衡有着多样化的需求。为此，TDengine 在 3.3.0.0 版本中推出了两种不同的企业级解决方案：双活方案和基于仲裁者的双副本方案，以满足不同应用场景下的特殊需求。本文将详细探讨这两种方案的适用场景、技术特点及其最佳实践，让大家深入了解这两大方案如何帮助企业在高效可靠的数据存储和管理中取得成功。
TDengine 双副本（+仲裁者）
为了满足部分客户在保证可靠性和可用性条件下尽可能压缩部署成本的需求，TDengine 提出了基于仲裁者的双副本方案。该方案通过提供“只有单个服务故障且不出现连续故障”的容错能力，成为客户降低成本和提高效率的有效选择。
相较于传统的三副本数据库，双副本数据库具有显著的优势。它在减少硬件成本的同时，依然能够保证一定的高可用性。具体来说，双副本数据库中每个 Vgroup 仅有两个 Vnode。当其中一个 Vnode 发生故障时，Mnode 可根据数据同步状态，裁定另一 Vnode 是否可以独自对外提供服务。这种机制确保了在某个副本节点故障时，数据不会丢失，并且系统能够持续进行写入和查询操作。
这一方案的适用场景广泛，面向有降低存储成本需求的、希望减少物理节点需求的客户，以及对高可用性要求稍低的客户。
从技术角度看，双副本方案具有以下几个显著特点：
– 副本数目：时序数据的副本数目为 2，但集群内节点数目必须大于等于 3。
– 自动切主：当时序数据的某个副本所在的物理节点宕机时，可以自动切换主节点，确保数据不丢失，并且能够持续写入和查询。
– 选主机制：双副本选主由高可用的 Mnode 提供仲裁服务，而不是由 Raft 组内决定。
仲裁者 (Arbitrator) 在双副本方案中发挥关键作用。它提供仲裁服务但不存储数据。当 Vgroup 因某一 Vnode 故障而无法提供服务时，Arbitrator 可以根据同步情况指定同组另一 Vnode 成为 Assigned Leader，无论其他副本 Vnode 是否存活，均可一直响应用户请求。这一机制确保了即使在某个副本节点故障的情况下，Assigned Leader 仍然能够一直响应用户请求，从而提高系统的可靠性和可用性。
TDengine 双活
部分用户由于部署环境的特殊性，只能部署两台服务器，同时希望实现一定的服务高可用和数据高可靠。针对这些需求，TDengine 提出了双活方案。双活方案不仅适用于一些资源受限的环境，也能在两套 TDengine 集群之间的灾备场景中发挥重要作用。
在业务系统中，双活架构通常包括两台服务器，各自部署一套服务。在业务层看来，这两台机器和两套服务组成了一个完整的系统。双活中的两个节点通常被称为 Master-Slave，即“主从”或“主备”。
双活方案在多个场景中都有广泛应用。首先，对于因部署环境特殊性只能部署两台服务器的客户，双活方案是理想选择。这些客户希望在有限的硬件资源下，仍然能够实现服务高可用和数据高可靠。其次，双活方案在工业控制领域中尤为适用。由于这些领域对系统可靠性和数据准确性有着极高的要求，双活架构能够很好地满足这些需求。此外，双活方案还适用于灾备场景，无论是资源受限的环境还是不限节点数目的两套 TDengine 集群之间的灾备场景，都能提供有效的解决方案。双活方案通过一系列技术机制实现高可用性和数据可靠性：
- 首先，系统通过 Client Driver 实现双系统的 Failover，即在主节点发生故障时，能够自动切换到从节点，确保服务不中断。
- 其次，taosX 实现了主节点到从节点的数据复制，通过数据订阅的写接口在写入复制过来的数据时，在 WAL 中加入特殊标记。
- 第三，数据订阅的读接口在读取数据时，会自动过滤掉带有特殊标记的数据，从而避免数据重复复制和无限循环。
当前，双活方案仅支持 JDBC 连接器和 WebSocket 连接方式，不支持 Native 连接。双活两端集群必须同构，即数据库的命名和所有配置参数必须完全相同，以确保系统的正确运行。
双副本 VS 双活，区别与实践
在 TDengine 的双副本和双活方案中，虽然它们都旨在提升数据可靠性和服务可用性，但两者在架构设计和实际应用中有着显著的区别。了解这些差异，对于选择合适的方案并实现最佳实践至关重要。
双活方案和双副本方案在集群架构上有明显的差异。双活方案需要部署两个独立的集群，每个集群内部的节点数可以任意多，而双副本方案只需部署一个集群，但集群内的节点数目必须大于等于三。这样一来，双活方案在集群内部节点数目上的灵活性更大，但同时也增加了部署和管理的复杂性。双活系统内的最小节点数为两个，也就是说每个集群至少有一个节点；相比之下，双副本系统的最小节点数为三个，以确保数据的可靠性和高可用性。
在同步原理上，双活方案通过 taosX 实现数据同步，依赖于 taosX 的同步速度，通常在秒级别。双副本方案则通过 Arbitrator 仲裁选主，由 Raft 协议保证数据的一致性，因此在同步延迟上表现更好，没有延迟。数据安全性方面，双活方案依赖于 WAL 的保存时长，而双副本方案则能确保无数据丢失。高可用性上，双活方案只要有一个节点存活即可提供服务，而双副本方案在连续宕机后，只有一个节点存活时，可能无法提供服务。
双副本最佳实践
- 全新部署
双副本的主要价值在于节省存储成本的同时能够有一定的高可用和高可靠能力。在实践中，推荐配置为：
- N 节点集群 （其中 N>=3）
- 其中 N-1 个 dnode 负责存储时序数据
- 第 N 个 dnode 不参与时序数据的存储和读取，即其上不保存副本；可以通过
supportVnodes这个参数为 0 来实现这个目标 - 不存储数据副本的 dnode 对 CPU/Memory 资源的占用也较低，可以使用较低配置服务器
- 从单副本升级
假定已经有一个单副本集群，其节点数为 N (N>=1)。将集群的节点数目扩展至 3 个以上，修改 Mnode 的副本数目为 3，在使用 alter database replica 2 的命令修改某个特定数据库的副本数。
双活最佳实践
双活系统通过数据复制实现双系统之间的数据同步，但这种同步只能保证最终一致性，无法确保实时一致性。主节点可能在任意时刻宕机，宕机时可能会有数据差集，尤其是元数据差集。在完成主备切换后，业务层可能会发起重复的建表请求，但 schema 可能不相同，导致元数据不一致。因此，建议在系统启动后集中完成所有建库建表操作，后续只写入时序数据，尽量避免再进行元数据操作。
结语
无论是双副本还是双活方案，TDengine 都为用户提供了强大的数据存储和管理解决方案。双副本方案在节省存储成本的同时，保证了一定的高可用性和数据可靠性，非常适合资源有限且需要高效数据管理的企业。双活方案则通过其灵活的架构和强大的灾备能力，为特殊部署环境和高可靠性需求的应用场景提供了理想的解决途径。通过理解这两种方案的区别和最佳实践，用户可以根据自身需求选择最适合的方案，充分利用 TDengine 的技术优势，打造稳定、高效的数据库系统。这不仅提升了业务连续性和数据安全性，更为企业的数字化转型提供了坚实的基础。
