TDengine TSDB 实战排障三（集群高可用）

核心问题：Sync leader is unreachable / Some vnode/qnode/mnode(s) are out of service / 掉一个节点到底会怎样 / 副本与仲裁怎么配

适用版本 ：TDengine TSDB 3.x（副本/仲裁/选举机制以 3.3+ 为准）

面向读者 ：集群规划与运维人员；被"掉一个节点整个集群不可用"困扰的实施工程师

文档定位 ：所有行为判定均给出源码位置（文件:行号），可自行核对

1. 先纠正三个最普遍的误解

误解一："三副本 = 可以挂两台"

事实：三副本只能挂一台。

TDengine 的副本同步走 Raft，提交需要多数派：

c 复制代码

// source/libs/sync/src/syncUtil.c:115
int32_t syncUtilQuorum(int32_t replicaNum) { return replicaNum / 2 + 1; }

副本数	多数派（quorum）	能容忍几个节点同时故障
1	1	0 个
2（+仲裁）	2	0 个（仲裁只能帮它"选出 leader"，不能帮它"凑够数据"）
3	2	1 个

三副本挂掉两台后只剩 1 个副本，凑不够 2 个确认，无法选主、无法写入，客户端会收到：

复制代码

Sync leader is unreachable [0x8000090C]

误解二："副本数可以随便设 2"

事实：社区版只允许 1 或 3；企业版允许 2，但必须同时启用仲裁节点。

c 复制代码

// source/dnode/mnode/impl/src/mndDb.c:543-548（建库校验，节选）
if ((pCfg->replications == 2) ^ (pCfg->withArbitrator == TSDB_MAX_DB_WITH_ARBITRATOR)) {
  return TSDB_CODE_MND_INVALID_DB_OPTION;      // 2 副本与仲裁必须同时出现
}
...
// 社区版：只允许 1 或 3

而且 2 副本和 3 副本之间不能互转 （mndDb.c:618-641，返回 TSDB_CODE_OPS_NOT_SUPPORT）。

误解三："`No enough dnodes` 是节点不够用"

事实：它的含义是"在线 dnode 数少于副本数"。

c 复制代码

// source/dnode/mnode/impl/src/mndVgroup.c:1054-1058
int32_t size = taosArrayGetSize(pArray);
if (size < pVgroup->replica) {
  mError("db:%s, vgId:%d, not enough online dnodes:%d to alloc %d replica", ...);
  TAOS_RETURN(TSDB_CODE_MND_NO_ENOUGH_DNODES);   // "Out of dnodes" (0x80000334)
}

集群里从没建过足够节点，或者部分节点当前是离线的，都会报这个错。

2. 先记住这五个数字

项	值	源码 / 文档依据
多数派公式	`replica / 2 + 1`	`syncUtil.c:115`
库副本数取值	1 / 3（企业版可 2，须配仲裁）	`mndDb.c:543-548`、`tdef.h:595-597`
mnode 数量上限	最多 3 个，最少 1 个	`mndMnode.c:744-747`、`mndMnode.c:909`
节点判离线超时	`statusTimeoutMs` 默认 5000 ms	`tglobal.c:68-71`
心跳/选举间隔	mnode 心跳 1000 ms、选举 4000 ms；vnode 同为 1000/4000 ms	`tglobal.c:220-223`

仲裁相关参数（企业版双副本）：

参数	默认值	含义
`arbHeartBeatIntervalSec`	2 s	仲裁心跳
`arbCheckSyncIntervalSec`	3 s	同步状态检查
`arbSetAssignedTimeoutSec`	14 s	指派 leader 的超时

来源：tglobal.c:249-254、tglobal.c:1200-1205。

3. 三分钟自查（TL;DR）

sql 复制代码

-- ① 集群整体可用性：0 不可用 / 1 完全可用 / 2 部分可用
show cluster alive;

-- ② 各节点在线状态与 vnode 占用
select id, endpoint, `vnodes`, support_vnodes, status from information_schema.ins_dnodes;

-- ③ mnode 的 role（找 leader）
select id, endpoint, role, status from information_schema.ins_mnodes;

-- ④ 每个 vgroup 各副本的状态（leader / follower / offline）
select vgroup_id, db_name, v1_dnode, v1_status, v2_dnode, v2_status, v3_dnode, v3_status, is_ready
from information_schema.ins_vgroups where db_name='<你的库>';

-- ⑤ 双副本场景：仲裁是否同步完成
show arbgroups;

判读要点

观察	结论
④ 里某 vgroup 只剩 1 个 `leader`、另两个 `offline`	三副本已失去多数派，写入会失败
② 里有节点 `status=offline`，`note` 有原因	先修节点，再谈其他
③ 里没有任何 `leader`	mnode 失去多数派，全局不可用
⑤ 中 `is_sync` 为 `false`	仲裁尚未完成同步，双副本此时不能切主
① 返回 `2`（部分可用）	有 vgroup 处于降级状态，需逐个查

4. 症状对号入座表

#	报错 / 现象	错误码	真实含义	章节
H1	`Sync leader is unreachable`	`0x8000090C`	凑不够多数派，选不出也有不到 leader	§6
H2	`Some vnode/qnode/mnode(s) are out of service`	`0x80000020`	部分节点不可达（常见于 hosts 未配全）	§5
H3	`Out of dnodes`	`0x80000334`	在线 dnode 数 < 副本数	§7
H4	`VGroup is offline`	`0x800003AE`	该 vgroup 当前不可读写（如单副本所在节点离线）	§6
H5	`Invalid option, wal_level 0 should be used with replica 1`	`0x8000039C`	`walLevel=0` 与多副本冲突	§8
H6	`Offline dnode exists`	`0x800003B6`	有节点离线时不允许做副本再平衡	§7
H7	`Vnodes exhausted`	`0x800003BA`	该节点 `supportVnodes` 用满	见第 02 篇
H8	`Cannot drop mnode which is leader`	`0x80000333`	不能删 leader mnode	§8
H9	`Mnode has not caught up with the leader`	`0x80000412`	新 mnode 还没追上 leader	§8
H10	`The replica of mnode cannot exceed 3`	`0x800003A9`	mnode 超过 3 个	§8
H11	`Sync timeout`	`0x80000903`	副本同步超时	§6
H12	`Sync write stall`	`0x80000917`	副本落后太多，写被减速	§6
H13	`Vgroup peer is not synced`	`0x80000537`	对端副本未同步	§8
H14	关掉一个节点后整个服务不可用	---	多为 mnode 单副本 + 该节点离线	§6.3
H15	升级后某些 vgroup 的 leader 分布不均	---	需要手动触发 leader 再平衡	§9

5. 决策树：先分清是"少数派"还是"连不上"

#mermaid-svg-bbcwvVnpkHDVSnfA{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-bbcwvVnpkHDVSnfA .error-icon{fill:#552222;}#mermaid-svg-bbcwvVnpkHDVSnfA .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-bbcwvVnpkHDVSnfA .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-bbcwvVnpkHDVSnfA .marker{fill:#333333;stroke:#333333;}#mermaid-svg-bbcwvVnpkHDVSnfA .marker.cross{stroke:#333333;}#mermaid-svg-bbcwvVnpkHDVSnfA svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-bbcwvVnpkHDVSnfA p{margin:0;}#mermaid-svg-bbcwvVnpkHDVSnfA .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA .cluster-label text{fill:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA .cluster-label span{color:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA .cluster-label span p{background-color:transparent;}#mermaid-svg-bbcwvVnpkHDVSnfA .label text,#mermaid-svg-bbcwvVnpkHDVSnfA span{fill:#333;color:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA .node rect,#mermaid-svg-bbcwvVnpkHDVSnfA .node circle,#mermaid-svg-bbcwvVnpkHDVSnfA .node ellipse,#mermaid-svg-bbcwvVnpkHDVSnfA .node polygon,#mermaid-svg-bbcwvVnpkHDVSnfA .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-bbcwvVnpkHDVSnfA .rough-node .label text,#mermaid-svg-bbcwvVnpkHDVSnfA .node .label text,#mermaid-svg-bbcwvVnpkHDVSnfA .image-shape .label,#mermaid-svg-bbcwvVnpkHDVSnfA .icon-shape .label{text-anchor:middle;}#mermaid-svg-bbcwvVnpkHDVSnfA .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-bbcwvVnpkHDVSnfA .rough-node .label,#mermaid-svg-bbcwvVnpkHDVSnfA .node .label,#mermaid-svg-bbcwvVnpkHDVSnfA .image-shape .label,#mermaid-svg-bbcwvVnpkHDVSnfA .icon-shape .label{text-align:center;}#mermaid-svg-bbcwvVnpkHDVSnfA .node.clickable{cursor:pointer;}#mermaid-svg-bbcwvVnpkHDVSnfA .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-bbcwvVnpkHDVSnfA .arrowheadPath{fill:#333333;}#mermaid-svg-bbcwvVnpkHDVSnfA .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-bbcwvVnpkHDVSnfA .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-bbcwvVnpkHDVSnfA .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-bbcwvVnpkHDVSnfA .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-bbcwvVnpkHDVSnfA .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-bbcwvVnpkHDVSnfA .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-bbcwvVnpkHDVSnfA .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-bbcwvVnpkHDVSnfA .cluster text{fill:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA .cluster span{color:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-bbcwvVnpkHDVSnfA .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-bbcwvVnpkHDVSnfA rect.text{fill:none;stroke-width:0;}#mermaid-svg-bbcwvVnpkHDVSnfA .icon-shape,#mermaid-svg-bbcwvVnpkHDVSnfA .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-bbcwvVnpkHDVSnfA .icon-shape p,#mermaid-svg-bbcwvVnpkHDVSnfA .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-bbcwvVnpkHDVSnfA .icon-shape .label rect,#mermaid-svg-bbcwvVnpkHDVSnfA .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-bbcwvVnpkHDVSnfA .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-bbcwvVnpkHDVSnfA .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-bbcwvVnpkHDVSnfA :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 0 不可用
2 部分可用
每个 vgroup 都还有 leader
某些 vgroup 已无 leader
1 完全可用
集群报错
show cluster alive 返回几
§6.3 mnode 层问题

查 ins_mnodes 有没有 leader
ins_vgroups 里

leader 还剩几个
§7 可写但降级

优先修离线节点
§6 失去多数派

凑不回多数派就只能等节点回来
§5 报错是客户端侧

多查 hosts / EP 解析

6. 副本、多数派与选举

6.1 写入为什么必须到 leader

写请求只认 leader，非 leader 会重定向并返回明确的错误码：

c 复制代码

// source/dnode/vnode/src/tsdb/... → source/dnode/vnode/src/vnd/vnodeSync.c:55-67（重定向）
// 非 leader 时构造重试 epset，并回 TSDB_CODE_SYN_NOT_LEADER

c 复制代码

// source/dnode/vnode/src/vnd/vnodeSvr.c:4640-4645
// vnodeCheckState：状态不是 leader → TSDB_CODE_SYN_NOT_LEADER

所以 0x8000090C 有两层含义：

客户端连到了 follower（正常现象，客户端会自动重试到 leader）；
整个 vgroup 没有 leader（异常，通常是凑不够多数派）。

区分方法：看 ins_vgroups 里该 vgroup 的 v1_status / v2_status / v3_status。若三个都不是 leader，属于第 2 种。

6.2 选举与状态机

副本状态取值（include/libs/sync/sync.h:78-86）：

值	状态	展示字符串
0	`OFFLINE`	`offline`
100	`FOLLOWER`	`follower`
101	`CANDIDATE`	`candidate`
102	`LEADER`	`leader`
103	`ERROR`	`error`
104	`LEARNER`	`learner`
105	`ASSIGNED_LEADER`	`assigned leader`

选举规则：

得票数 ≥ quorum 才能当选（syncVoteMgr.c:64）；
单副本时自投即 leader，启动直接 syncNodeBecomeLeader（syncElection.c:117-126、syncMain.c:1616-1621）；
learner（学习者）没有投票权 （TSDB_CODE_SYN_LEARNER_NO_VOTE）。

6.3 为什么"关一台机器，整个集群就不可用"

这一类投诉在代码上有三个常见对应：

根因	代码依据	表现
mnode 是单副本，且正好落在被关的节点上	`mndIsLeader` 找不到 leader（`mndSync.c:740-760`）	全局不可用，客户端报 `0x80000020`
vgroup 是单副本，其所在节点离线	`TSDB_CODE_MND_VGROUP_OFFLINE`（`mndDb.c:2340`）	该库不可读写
三副本但同时关了两台	凑不够 quorum	`0x8000090C`

规划建议（从代码推出来的）：mnode 至少 3 个、库副本数为 3，才能真正容忍"任意一台机器下线"。只加库副本、不给 mnode 加副本，集群仍会全局不可用。

6.4 节点是怎么被判"离线"的

c 复制代码

// source/dnode/mnode/impl/src/mndDnode.c:422-431
// mndIsDnodeOnline：|lastAccessTime - curMs| <= tsStatusTimeoutMs 才算在线
// 超时 → offlineReason = DND_REASON_STATUS_MSG_TIMEOUT

statusInterval 默认 1 s，statusTimeoutMs 默认 5000 ms；节点必须连续 5 秒没上报才被判离线。
未上报 vnode 时还有一个宽限窗口：max(3 × statusIntervalMs, statusTimeoutMs)（mndDnode.c:1212-1265），默认也是 5 秒。
判定离线的瞬间，mnode 会把该节点上所有 vnode 的 syncState 置为 OFFLINE（mndMain.c:354-399），这就是你在 show vgroups 里看到 offline 的来源。

网络抖动导致 statusTimeoutMs 内没收到心跳，也会被误判离线。跨机房部署时可适当调大 statusTimeoutMs。

7. vgroup 是怎么分布到节点上的

7.1 打分选节点

c 复制代码

// source/dnode/mnode/impl/src/mndVgroup.c:1019-1045
// 打分公式（越小的节点越优先）
// score = (numOfVnodes + numOfOtherNodes * 0.9 + add) / numOfSupportVnodes

排序后取前 replica 个 dnode（mndVgroup.c:1054-1073）。遇到问题依次返回：

检查	不通过的错误码
在线 dnode 数 < replica	`0x80000334` `Out of dnodes`
`numOfVnodes >= numOfSupportVnodes`	`0x800003BA` `Vnodes exhausted`
内存额度不足	`0x800003B1` `No enough memory in dnode`

7.2 副本分布的顺序

mndSortVnodeGid 按 dnodeId 升序排列（mndVgroup.c:1033-1041），这决定了 show vgroups 里 v1_dnode / v2_dnode / v3_dnode 的顺序------排查时不要假设 v1 就是 leader。

7.3 再平衡（rebalance）

有节点离线时禁止再平衡：

c 复制代码

// source/dnode/mnode/impl/src/mndVgroup.c:2732-2744
// 存在离线 dnode → TSDB_CODE_MND_HAS_OFFLINE_DNODE (0x800003B6)

带仲裁节点的库不参与自动 balance （mndVgroup.c:3936，日志 "with arbitrator, balance vgroup not allowed"）。

8. 副本与仲裁的配置边界

操作	结果	依据
社区版配 `replica 2`	拒绝	`mndDb.c:548`
企业版配 `replica 2` 但不带仲裁	拒绝（`MND_INVALID_DB_OPTION`）	`mndDb.c:543-545`
2 副本 ↔ 3 副本互转	拒绝（`OPS_NOT_SUPPORT`）	`mndDb.c:618-641`
`walLevel=0` + 多副本	拒绝（`0x8000039C`）	`mndDb.c:618-641`
副本数 > 在线 dnode 数	拒绝（`0x80000334`）	`mndDb.c:556`
建第 4 个 mnode	拒绝（`0x800003A9`）	`mndMnode.c:744-747`
同一个 dnode 上建 2 个 mnode	拒绝	`test/cases/70-Cluster/test_5dnode1mnode.py:96`
删 leader mnode	拒绝（`0x80000333`）	文档 `05-tdengine-sql/08-cluster-management/01-node.md`

双副本 + 仲裁的关键机制：

每个 vgroup 生成一个 arbToken（syncMain.c:1305）；
仲裁端超时判定：lastHbMs < nowMs - tsArbSetAssignedTimeoutMs（mndArbGroup.c:552）；
vnode 侧校验 token，不匹配 → TSDB_CODE_MND_ARB_TOKEN_MISMATCH（vnodeSvr.c:4640-4705）；
仲裁通过后副本进入 ASSIGNED_LEADER（105）状态。

双副本是企业版 能力（3.3.0.0 起），并且需要额外部署 arbitrator 进程、配套 arbHeartBeatIntervalSec 等参数。

9. 运维动作：掉节点前 / 后该做什么

9.1 计划内停机（滚动升级、换硬件）

sql 复制代码

-- 先看哪些 vgroup 的 leader 在目标节点上
select vgroup_id, db_name, v1_dnode, v1_status, v2_dnode, v2_status, v3_dnode, v3_status
from information_schema.ins_vgroups;

-- 逐个把 leader 迁走（避免停机后被选主）
balance vgroup leader;                                  -- 全部
balance vgroup leader database <db_name>;               -- 指定库
balance vgroup leader on <vgroup_id>;                   -- 指定 vgroup

balance 的完整语法见 docs/zh/12-operations-and-tooling/02-operations/04-maintenance.md:72-79。

9.2 节点已经离线

sql 复制代码

-- 看离线原因（note 列会写明，例如 status 消息超时、版本不匹配）
select id, endpoint, status, note from information_schema.ins_dnodes;

-- 看哪些 vgroup 受影响：status 为 offline 的那一列
select vgroup_id, db_name, v1_dnode, v1_status, v2_dnode, v2_status, v3_dnode, v3_status
from information_schema.ins_vgroups;

恢复优先级：先让节点回来（多数派会自动恢复），再考虑数据修复。

9.3 删除节点

sql 复制代码

-- 在线节点：可以直接删
drop dnode <id>;

-- 单副本且已离线：必须加 UNSAFE（数据不可再恢复，慎用）
drop dnode <id> unsafe;

来源：docs/zh/05-tdengine-sql/08-cluster-management/01-node.md:31-37。

9.4 数据一致性自查

sql 复制代码

scan;                       -- 全量一致性扫描（异步）
scan start with <ts> end with <ts>;
show scans;                 -- 查看进度
kill scan <id>;             -- 取消

来源：docs/zh/12-operations-and-tooling/02-operations/04-maintenance.md:55-64。

10. 参数速查表

参数	默认值	单位	范围	作用
`statusInterval`	1	秒	50 ~ 30000（ms）	dnode 状态上报间隔
`statusTimeoutMs`	5000	ms	50 ~ 30000	多久未上报判为离线
`syncElectInterval`	4000	ms	10 ~ 172800000	mnode 选举间隔
`syncHeartbeatInterval`	1000	ms	10 ~ 172800000	mnode 心跳间隔
`syncVnodeElectIntervalMs`	4000	ms	10 ~ 172800000	vnode 选举间隔
`syncVnodeHeartbeatIntervalMs`	1000	ms	10 ~ 172800000	vnode 心跳间隔
`syncTimeout`	0	ms	0 ~ 172800000	同步超时（0 = 不额外限制）
`arbHeartBeatIntervalSec`	2	秒	---	仲裁心跳
`arbCheckSyncIntervalSec`	3	秒	---	仲裁同步检查
`arbSetAssignedTimeoutSec`	14	秒	---	指派 leader 超时
`supportVnodes`	核数 × 2 + 5	个	0 ~ 1024	单节点 vnode 上限

来源：tglobal.c 各注册行；文档 docs/zh/12-operations-and-tooling/03-components/01-taosd.md。

11. 五个最常见的错误认知

#	错误认知	事实
1	"三副本能挂两台"	`quorum = replica/2 + 1`，三副本只能挂一台
2	"副本数可以设 2"	社区版只允许 1 或 3；企业版 2 副本必须配仲裁节点
3	"库配了 3 副本就高可用了"	mnode 若为单副本，它所在节点离线仍会全局不可用
4	"看到 `Sync leader is unreachable` 就说明集群坏了"	连到 follower 也会报它，客户端会自动重定向；只有所有副本都不是 leader 才是真故障
5	"节点一离线就能做再平衡"	存在离线 dnode 时会直接拒绝（`0x800003B6`）；带仲裁的库也不参与自动 balance

附：集群问题提工单时建议一并收集的信息

text 复制代码

【集群规模】dnode 数、mnode 数、每个库的副本数与 vgroups
【可用性】show cluster alive 的返回值
【节点】select id, endpoint, `vnodes`, support_vnodes, status, note from information_schema.ins_dnodes;
【mnode】select id, endpoint, role, status from information_schema.ins_mnodes;
【vgroup】select vgroup_id, db_name, v1_dnode, v1_status, v2_dnode, v2_status, v3_dnode, v3_status, is_ready from information_schema.ins_vgroups;
【仲裁】show arbgroups;（双副本场景）
【参数】statusTimeoutMs、syncElectInterval、syncHeartbeatInterval、supportVnodes 的实际取值
【时间线】故障发生与恢复的准确时间点、期间做过什么操作
【服务端日志】离线前后的 taosdlog（grep -i "offline\|not leader\|quorum"）

TDengine TSDB 实战排障三（集群高可用）

1. 先纠正三个最普遍的误解

误解一："三副本 = 可以挂两台"

误解二："副本数可以随便设 2"

误解三："No enough dnodes 是节点不够用"

2. 先记住这五个数字

3. 三分钟自查（TL;DR）

4. 症状对号入座表

5. 决策树：先分清是"少数派"还是"连不上"

6. 副本、多数派与选举

6.1 写入为什么必须到 leader

6.2 选举与状态机

6.3 为什么"关一台机器，整个集群就不可用"

6.4 节点是怎么被判"离线"的

7. vgroup 是怎么分布到节点上的

7.1 打分选节点

7.2 副本分布的顺序

7.3 再平衡（rebalance）

8. 副本与仲裁的配置边界

9. 运维动作：掉节点前 / 后该做什么

9.1 计划内停机（滚动升级、换硬件）

9.2 节点已经离线

9.3 删除节点

9.4 数据一致性自查

10. 参数速查表

11. 五个最常见的错误认知

附：集群问题提工单时建议一并收集的信息

误解三："`No enough dnodes` 是节点不够用"