TDengine 高可用方案完全指南：三副本、双副本仲裁与双活（Active-Active）架构解析与实战

TDengine 高可用方案完全指南三副本、双副本仲裁与双活Active-Active架构解析与实战【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengineTDengine 作为面向工业物联网IIoT场景的高性能时序数据库其内置的高可用High Availability, HA能力可以确保在单个节点不可用时不中断服务、不丢失数据。本文基于 docs/en/12-operations-and-tooling/02-operations/11-ha 系列文档系统讲解 TDengine 的三种高可用部署形态——Raft 三副本、仲裁器双副本与基于 taosX 的双活——的架构原理、集群搭建、维护命令、故障场景与 FAQ并结合仓库源码与底层架构文档进行纵深剖析。读完本文你将掌握如何按业务对成本、一致性与可用性的要求选择并落地最适合的 TDengine 高可用方案。默认情况下TDengine 基于 Raft 算法提供标准的三副本架构为了适配不同部署场景TDengine 还提供了基于 Raft 的双副本选项配合仲裁器以及面向传统主备习惯的、通过 WAL 数据同步实现的双活active-active方案。三种方案的对比如下表#三副本Three-Replica双副本Dual-Replica双活Active-Active集群形态单一集群单一集群两个独立集群最少节点数三个数据节点两个数据节点 一个仲裁节点两个数据节点选主方式Raft 算法仲裁器Arbitrator管理不适用复制方式Raft 算法Raft 算法taosX同步延迟无无取决于 taosX通常为数秒数据持久性不丢数据不丢数据取决于 WAL 保留时长数据一致性强一致Raft强一致Raft最终一致可用性任一单节点故障服务不受影响单节点故障服务不受影响但无法容忍连续故障只要有一个实例存活即可持续服务一、三副本架构基于 Raft 的强一致高可用1.1 工作原理TDengine 的三副本配置使用 Raft 算法同时保证元数据与时序数据的一致性。每个vgroup即是一个 Raft 组组内的vnode是 Raft 组成员也就是常说的副本。其核心工作过程如下每个 vnode 拥有一个角色leader领导者、follower跟随者或candidate候选者每个 vnode 维护一份连续日志记录插入、更新、删除等所有操作。日志由一系列有序条目组成每个条目都有唯一标识用于追踪共识进度与执行情况leader vnode 对外提供读写服务。只要多数节点存活服务即可保持高可用。即使发生节点重启或 leader 重新选举Raft 算法也能保证新 leader 始终能提供所有已成功写入的数据对数据库的每一次变更请求例如一次数据插入都对应一条日志条目。持续写入过程中Raft 保证所有成员节点以相同顺序生成相同的日志条目并一致地应用对应变更这些日志以WALwrite-ahead log预写日志文件形式保存在数据目录中只有当日志条目被追加到多数节点的 WAL 文件并收到确认后该条目才算安全进入committed已提交状态数据变更随之落定应用完成后该日志条目被标记为applied已应用。更完整的多副本写入与复制过程参见仓库文档 Data Writing and Replication Processleader 写入流程leader 收到写入请求并校验通过后先将原始数据包写入 WAL若wal_level为 2 且wal_fsync_period为 0则立即持久化 WAL 到磁盘以防崩溃丢数据随后将数据包连同版本号version转发给同 vgroup 内的 follower再写入内存并加入跳表若未达成共识则回滚最后向应用返回确认。步骤 2/3/4 任一失败都会直接向应用报错见 01-arch.md。同步复制Synchronous Replicationleader 转发写请求后不会立刻通知应用写入成功而是等待**超过半数副本含自身**确认后才返回成功若在限定时间内未获多数确认则返回错误见 01-arch.md。这也是三副本“强一致、不丢数据、无同步延迟”结论的底层来源。从源码看Raft 状态机与选主逻辑位于 source/libs/sync/src/syncMain.c其中ESyncRole枚举了 follower/leader 等角色vnode 启动后通过与其他节点交换版本号与 term 完成选主参见 01-arch.md 的 Leader Selection 小节。1.2 集群配置步骤三副本架构要求至少三台服务器节点基本部署配置步骤如下确定服务器节点数量及其主机名或域名配置 DNS 或/etc/hosts保证名称解析正常在每个节点安装 TDengine 服务端包并按需编辑各节点的taos.cfg在各节点启动taosd服务其他服务如taosadapter、taosx、taoskeeper、taos-explorer按需启动。1.3 维护命令创建集群——在集群中再创建两个 dnode使总数达到三个CREATE dnode dnode_ep port dnode_port; CREATE dnode dnode_ep port dnode_port;在两个 dnode 上创建 mnode使 mnode 总数达到三个CREATE mnode on dnode dnode_id; CREATE mnode on dnode dnode_id;创建三副本数据库create database dbname replica 3 vgroups xx buffer xx ...说明replica参数决定数据库副本数vgroups指定 vgroup 数量buffer指定每 vnode 内存缓冲大小其余建库参数如wal_level、cache、pages等均可按需追加完整语法见 05-tdengine-sql 文档 相关章节。修改已有数据库——若数据库此前副本数不足 3可将其改为三副本alter database dbname replica 3|1关于副本数与 vgroup 的对应关系可参考 01-arch.mdvgroup 内 vnode 数即数据副本数要创建 N 副本数据库集群至少要有 N 个 dnode。1.4 常见问题FAQQ1创建或修改数据库为三副本时报DB error: Out of dnodes原因集群中服务器节点少于三个。解决确保创建三副本数据库前集群至少有 3 个 dnode。Q2创建三副本数据库或执行 SPLIT VGROUP 时报DB error: Vnodes exhausted原因部分 dnode 可用 vnode 数少于建库或 vgroup 拆分所需数量。解决增加 dnode 的 CPU 核数或修改SupportVnodes参数该参数表示 dnode 可支持的最大 vnode 数见 04-maintenance.md。二、双副本架构仲裁器 Raft 的成本优化方案2.1 工作原理与角色TDengine 提供基于仲裁器的双副本方案其容错前提是同一时刻只有一个节点故障、且故障不连续。相比三副本双副本降低了硬件成本同时保留一定的高可用能力。注意双副本arbitrator 仲裁为 TDengine EnterpriseTSDB Enterprise能力部署需使用企业版服务端包。在此架构中选主由高可用的 mnode 通过仲裁完成而不是在 Raft 组内部决定Arbitrator仲裁器只提供仲裁服务不存储数据。当 vgroup 因 vnode 故障而不可用时仲裁器会基于数据同步状态指定 vgroup 中的另一个 vnode 为assigned leader指派 leaderAssigned Leader指派 leader被显式指定为 leader 的 vnode。无论另一个副本 vnode 是否存活它都可以继续服务客户端请求。从源码实现看仲裁组信息由 mnode 维护SArbGroup结构包含成员状态、isSync同步状态、assignedLeader指派 leader 的 dnodeId 与 token等字段其序列化与状态更新逻辑位于 source/dnode/mnode/impl/src/mndArbGroup.c指派 leader 时涉及的 token 校验与 step down 处理generate arb token, will step down from assigned leader可在 source/libs/sync/src/syncMain.c 附近看到印证了“指派 leader 基于 token 授权”的实现细节。2.2 集群配置步骤双副本架构同样要求至少三台服务器节点确定节点数量及主机名/域名配置 DNS 或/etc/hosts在每个节点安装TDengine TSDB-Enterprise服务端包并按需编辑taos.cfg可指定一台节点仅提供仲裁服务即部署 mnode 并将SupportVnodes参数设为 0表示不存储时序数据。该节点资源占用极低仅需 1–2 个 CPU 核可与其它应用共置运行启动各节点的taosdtaosadapter、taosx、taoskeeper、taos-explorer等服务按需启动。supportVnodes参数原本配置于taos.cfg自 3.1.1.0 起 TDengine Enterprise 支持对其在线热更新建库时分配新 vnode、删库时销毁 vnode 都会影响该参数的余量见 04-maintenance.md。该参数在源码中对应 dnode 的numOfSupportVnodes状态字段其变化会触发 mnode 对 dnode 状态的重新检查见 source/dnode/mnode/impl/src/mndDnode.c。2.3 限制Limitations最小服务器配置为两个数据节点 一个仲裁节点副本数是数据库级参数不同数据库可按需选择副本数支持 TDengine 全部功能特性支持全部语言连接器与连接方式可在单副本与双副本之间切换前提是节点数、可用 vnode、内存与存储空间满足要求不能在双副本与三副本模式之间切换不能从双副本模式切换到双活模式除非额外部署一个独立实例以组成双活架构。2.4 维护命令创建集群——创建两个 dnode 使总数达到三个CREATE dnode dnode_ep port dnode_port; CREATE dnode dnode_ep port dnode_port;创建两个 mnode 使总数达到三个CREATE mnode on dnode dnode_id; CREATE mnode on dnode dnode_id;创建双副本数据库create database dbname replica 2 vgroups xx buffer xx ...修改已有数据库——将单副本数据库改为双副本alter database dbname replica 2;查看 vgroup 状态show arbgroups; select * from information_schema.ins_arbgroups;查询结果示例db_name | vgroup_id | v1_dnode | v2_dnode | is_sync | assigned_dnode | assigned_token | db | 2 | 2 | 3 | 0 | NULL | NULL | db | 3 | 1 | 2 | 0 | 1 | d1#g3#1714119404630#663 | db | 4 | 1 | 3 | 1 | NULL | NULL |字段含义is_sync有两个取值0vgroup 数据尚未完成同步。此时若组内一个 vnode 不可达另一 vnode 不能被指派为AssignedLeader角色vgroup 将无法提供服务1vgroup 数据已完成同步。此时若一个 vnode 不可达另一 vnode 可被指派为AssignedLeadervgroup 可继续提供服务。assigned_dnode被指派为AssignedLeader的 vnode 所在的 DnodeId未指派时显示NULLassigned_token被指派为AssignedLeader的 vnode 的 Token未指派时显示NULL。SHOW ARBGROUPS与information_schema.ins_arbgroups等价均展示仲裁组内副本 dnode、同步状态与指派 token 信息该信息对SYSINFO权限为 0 的用户不可见见 01-meta.md 与 03-show.md。2.5 最佳实践场景一新建部署双副本的核心价值在于省存储成本的同时保留一定的高可用与可靠性。推荐配置N 节点集群N3N-1 个 dnode 负责存储时序数据第 N 个 dnode 不参与时序数据的存储与检索不存副本可通过将supportVnodes设为 0 实现不存副本的 dnode CPU/内存占用更低可使用低配服务器。场景二从单副本升级假设已有 N 个节点N1的单副本集群希望升级为双副本集群先保证升级后 N3并为新增节点配置supportVnodes为 0完成集群升级后用alter database replica 2将指定数据库改为双副本。2.6 故障场景一览场景结果仲裁器故障两个及以上 mnode 宕机服务可用vgroup 完成同步后的单 vnode 故障服务可用vgroup 完成同步后的双 vnode 故障但其中一个恢复可执行ASSIGN LEADER FORCE;语句恢复服务vgroup 完成同步前的单 vnode 故障服务不可用双 vnode 故障服务不可用强制指派 leader 语句ASSIGN LEADER FORCE;2.7 常见问题FAQQ1创建或修改数据库为双副本时报DB error: Out of dnodes原因集群中数据节点少于两个。解决确保创建双副本数据库前集群至少有 2 个 dnode。Q2创建双副本数据库或执行 SPLIT VGROUP 时报DB error: Vnodes exhausted原因部分 dnode 可用 vnode 数不足。解决增加 dnode 的 CPU 核数或修改SupportVnodes参数。三、双活Active-Active架构基于 taosX 的 WAL 级同步3.1 架构原理双活模式让你在有限资源下获得高可用与高可靠也常用于**容灾disaster recovery**场景在异地维护数据库副本。重要提示TDengine 3.4.x 当前不支持双活模式。双活模式下你创建两套独立的 TDengine 部署一套作为主节点primary另一套作为从节点secondary数据通过taosX在主从之间实时复制。每套部署既可以是单实例也可以是集群。当主节点无法提供服务时客户端驱动自动切换到从节点——这种故障转移对业务层是自动且透明的。双活系统的核心机制有三点架构见下图实时复制taosX 同步 WAL 数据、自动故障转移客户端驱动感知主节点故障并切换、防环路标记被复制的数据会被特殊标记避免主从之间的复制形成无限循环。注上图中每个“主机”在真实场景中可以代表任意规模的 TDengine 集群。3.2 集群配置双活模式无需为集群做特殊配置但要注意WAL 保留时长WAL retention period直接影响双活部署的容错能力若从节点不可达的时长超过WAL 保留时长将发生数据丢失且此类丢失只能人工恢复若从节点不可达的时长未超过WAL 保留时长仍存在丢数据可能具体取决于停机时长与保留时长的接近程度以及数据同步速度。3.3 客户端配置双活模式目前仅 Java 客户端库的 WebSocket 连接模式支持。示例配置url jdbc:TAOS-WS:// host :6041/?userrootpasswordtaosdata; Properties properties new Properties(); properties.setProperty(TSDBDriver.PROPERTY_KEY_SLAVE_CLUSTER_HOST, 192.168.1.11); properties.setProperty(TSDBDriver.PROPERTY_KEY_SLAVE_CLUSTER_PORT, 6041); properties.setProperty(TSDBDriver.PROPERTY_KEY_ENABLE_AUTO_RECONNECT, true); properties.setProperty(TSDBDriver.PROPERTY_KEY_RECONNECT_INTERVAL_MS, 2000); properties.setProperty(TSDBDriver.PROPERTY_KEY_RECONNECT_RETRY_COUNT, 3); properties.setProperty(TSDBDriver.PROPERTY_KEY_VARCHAR_AS_STRING, true); connection DriverManager.getConnection(url, properties);参数说明属性说明PROPERTY_KEY_SLAVE_CLUSTER_HOST从节点的主机名或 IP 地址。PROPERTY_KEY_SLAVE_CLUSTER_PORT从节点的端口号。PROPERTY_KEY_ENABLE_AUTO_RECONNECT是否启用自动重连。双活模式下必须设为true。PROPERTY_KEY_RECONNECT_INTERVAL_MS重连尝试间隔毫秒默认 2000可设为 0 表示立即重连无上限。PROPERTY_KEY_RECONNECT_RETRY_COUNT每个节点的最大重试次数默认 3无上限。3.4 限制Limitations双活模式启用时不能使用数据订阅 API双活模式启用时不能使用参数绑定接口不能使用USE database语句设置上下文应在连接参数中指定数据库主从节点必须完全一致数据库名、全部配置参数、用户名、密码与权限设置必须完全相同仅支持 WebSocket 连接模式。3.5 维护命令启动双活模式taosx replica start启动双活场景的数据复制任务前两台主机上的taosd 与 taosX 都必须运行。有两种启动方式方式一指定源/目标端点taosx replica start -f source_endpoint -t sink_endpoint [database...]在本地 taosx 服务中创建从source_endpoint到sink_endpoint的同步任务成功后控制台会打印 replica ID下文以id表示。source_endpoint与sink_endpoint为必填参数格式为td2:6030。示例taosx replica start -f td1:6030 -t td2:6030该命令会自动为除information_schema、performance_schema、log、audit之外的所有数据库创建同步任务并持续监控新建数据库当 td1 与 td2 上出现同名新库时自动为其创建新的复制任务。注意事项端点也可使用 WebSocket 接口默认为原生接口写法如http://td2:6041可用--new-database-checking-interval SECONDS配置新库检查间隔默认 30 分钟可用--no-new-databases禁用新库监控也可只复制指定数据库如taosx replica start -f td1:6030 -t td2:6030 db1只为指定库创建任务。此时等价于启用--no-new-databases不会自动复制新建库。方式二基于已有 replica ID 追加数据库taosx replica start -i id [database...]使用已有 replica ID 向复制任务追加数据库。注意重复执行该命令不会产生重复任务只会把指定数据库加入既有任务replica ID 在单个 taosX 实例内全局唯一与 source/sink 组合无关为便于记忆replica ID 由常见随机单词生成系统自动为每个 source/sink 组合从词表分配唯一可用单词。查看任务状态taosx replica status [id...]返回本机创建的双活复制任务列表及状态可指定一个或多个 replica ID 查看对应任务详情。示例输出-------------------------------------------------------------------------- | replica | task | source | sink | database | status | note | -------------------------------------------------------------------------- | a | 2 | td1:6030 | td2:6030 | opc | running | | | a | 3 | td2:6030 | td2:6030 | test | interrupted | Error reason |停止双活模式taosx replica stop id [db...]停止指定 replica ID 下的全部或仅指定数据库的双活复制任务。例如taosx replica stop id1 db1停止 replicaid1下db1的复制任务。若启用了--no-new-databases新库监控任务不会被停止仅停止当前运行中的数据库复制。重启双活模式taosx replica restart id [db...]重启指定 replica ID 下的全部或仅指定数据库的双活复制任务。例如taosx replica restart id1 db1重启 replicaid1下db1的复制任务。查看同步进度taosx replica diff id [db....]输出当前同步任务中已订阅偏移量与最新 WAL 的差值。注意该差值不代表行数。示例-------------------------------------------------------------------------- | replica | database | source | sink | vgroup_id | current | latest | diff | -------------------------------------------------------------------------- | a | opc | td1:6030 | td2:6030 | 2 | 17600 | 17600 | 0 | | a | opc | td2:6030 | td2:6030 | 3 | 17600 | 17600 | 0 |删除同步任务taosx replica remove id [--force]删除指定 replica ID 下的全部双活复制任务。通常需先停止任务再删除使用--force时任务被强制停止并清除。若启用了--no-new-databases新建库的复制任务不会被删除仅移除当前运行中的数据库复制taosX 重启后若被删数据库仍存在对应复制任务会被重新创建若 taosX 未重启或双活监控任务未更新则不会再次创建这些任务。更新新库检查间隔taosx replica update id --new-database-checking-interval SECONDS更新双活场景下新建数据库检查间隔秒。3.6 推荐使用流程在机器 A 上运行taosx replica start配置 taosX输入参数为同步的源与目标服务器地址配置完成后同步服务与任务自动启动示例中 taosX 服务使用标准端口复制任务使用原生连接在机器 B 上重复相同步骤两台机器上的服务都启动后双活系统即可对外提供服务若系统已配置过、需要再次启动使用 restart 子命令即可。3.7 故障排查若停机恢复时长超过 WAL 保留时长可能发生数据丢失。此时双活系统内置 taosX 的自动数据同步无法解决该问题必须人工介入先识别丢失了哪些数据再启动一个额外的 taosX 任务来复制缺失数据。四、方案选型总结综合以上三种方案可按如下原则选型追求最高可用性与强一致、硬件成本不敏感选择三副本Raft任一单节点故障服务不受影响写入多数派确认、不丢数据希望降低成本但保留强一致与一定容错能力选择双副本 仲裁器两台数据机加一台低配仲裁机即可但无法容忍连续故障且仅限 TDengine Enterprise希望以两节点获得可用性、可接受最终一致选择双活taosX WAL 同步常用于容灾场景需特别注意 WAL 保留时长与故障转移窗口对数据完整性的影响且当前版本3.4.x暂不支持。三套方案的维护命令与故障表现差异明显建议在部署前结合仓库中的高可用文档11-ha 目录与集群管理 SQL 文档08-cluster-management做完整预案并在测试环境完成故障演练后再投入生产。【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考