很多用户搭 TDengine 集群时,第一步就卡在副本数该设多少“某台机器挂了数据会不会丢”“切换是自动的还是要我手动操作”。这篇文章把这几个问题讲清楚,结论都对照了源码中的实现逻辑。副本数只能设 1、2 或 3,不是随便一个数字创建数据库时的REPLICA参数(有效范围 1~3)决定了这个库的每个 vgroup 有几份数据副本。这里有几个容易被忽略的约束,都是在服务端强制校验的:REPLICA 2是一种特殊模式,必须同时配置仲裁节点(arbitrator),不能单独使用——这和很多人以为的2 副本就是普通双机热备不一样。REPLICA大于 1 时,WAL_LEVEL必须至少为 1(不能设成 0),否则副本之间就没有可靠的数据来源做同步。集群里可用的 dnode(数据节点)数量必须不少于你设置的副本数,否则建库会直接报错。建议:生产环境如果要做高可用,直接用REPLICA 3(需要至少 3 台 dnode),避免用REPLICA 2这种依赖仲裁节点的过渡形态,除非你清楚它的运维方式。每个 vgroup 都是一个独立的小集群,自己选主TDengine 的多副本一致性是基于类似 Raft 的共识机制实现的(内部称为 sync 模块)。关键点是:这个选主机制不是全局一份,而是每个 vgroup 各自独立运行一套——每个 vgroup 有自己的 leader 副本和若干 follower 副本,写入只能落到 leader 上,再同步给 follower。好处是故障影响范围是局部的:一个 vgroup 的 leader 出问题,不会影响其他 vgroup 的读写,只有这一个 vgroup 会经历短暂的重新选主过程。mnode(管理节点)用的是同一套机制,但节点数上限是 3集群的元数据管理节点(mnode)本质上也是跑在这套共识引擎之上的,只是它管理的是元数据这个特殊的逻辑分组。有一个明确的硬限制:一个集群最多只能有 3 个 mnode,超过会被服务端直接拒绝。生产环境建议部署 1 个(测试/单机场景)或 3 个(需要元数据高可用的场景), 另外企业版也支持 2 副本最少只需要两台服务器即可形成一个集群减少服务器数量。节点挂了之后,切换是自动的,但前提是有副本当某个 vgroup(或 mnode 所在分组)的 leader 副本因为宕机等原因停止响应,其他副本会在检测到心跳超时后自动发起重新选主,选出新的 leader 继续提供服务——这个过程是自动完成的,不需要人工介入触发切换。但要注意一个边界情况:如果你的库是REPLICA 1(单副本),这个 vgroup 就没有其他副本可以顶上,对应的 dnode 挂了之后,这部分数据在该节点恢复之前就是不可用的,谈不上自动切换——因为压根没有可切换的对象。这也是为什么高可用不是部署了集群就自动获得的能力,而是取决于你在建库时选的副本数。如果业务对可用性要求高,该用REPLICA 3;如果只是想水平扩展写入/存储容量、能接受单点故障带来的短暂数据不可用,REPLICA 1也是合理选择,但要清楚这个取舍。小结规划 TDengine 集群高可用时,记住三件事:副本数决定了故障时有没有备胎可以顶上;每个 vgroup 独立选主,故障是局部的不是全局的;mnode 最多 3 个,规划集群规模时不要超配。选主和切换的机制是自动的,用户唯一需要主动决策的是副本数这个入口参数。