XDCR 的 status 输出并不是一个简单的健康标志，它更像一层运行快照，告诉用户当前复制任务是否被调度器拉起、是否在执行数据同步。真正判断复制是否健康，必须把 status 和 changesLeft、docsChecked、errorsSeen 等计数指标放在一起看。很多故障场景中，status 仍然显示 Running，但目标端文档数量已经长时间没有增长。
理解这一点后，就可以避免把界面上的绿色状态当成数据同步完成。下面从字段含义、查询手段和排查思路三个角度展开。
一、XDCR status 的层级与关键字段
Couchbase XDCR 的状态至少可以拆成三个层级来看。第一层是复制任务状态，它由每个节点上的 goXDCR 进程维护，反映该复制定义是否被调度、是否处于运行中、是否被手动暂停或失败退出。第二层是目标集群连接状态，也就是源集群到远端引用之间的网络链路是否可用。第三层才是文档级写入结果，它记录在 XDCR 的统计指标里，而不是直接体现在 status 字段上。
任务状态常见的取值包括 Starting、Running、Paused、Failed 和 Stopping。其中 Running 只表示复制任务正在执行，并不说明数据已经追平。真正判断同步积压要看 changesLeft，它表示源端还有多少变更没有复制到目标端。docsChecked 是源端已经扫描过的变更数量，docsWritten 是实际写入目标端的文档数量，errorsSeen 和 docsFailed 则记录复制过程中出现的错误和失败写入。
举例来说，如果源端写入速度突然增大，status 可能一直保持 Running，但 changesLeft 会持续堆积。反过来，如果 changesLeft 回到 0，说明当前已经追平，但不代表之后的写入不会再次产生积压。因此巡检时不能只盯 status，要把任务状态和统计指标当成一组数据来读。
二、通过 REST API 和命令行获取实时状态
最直接的查询方式是调用 Couchbase 的 REST API，其中 /pools/default/tasks 接口会返回当前集群的所有任务列表，里面包含类型为 xdcr 的复制任务。通过 jq 过滤可以快速拿到每个复制的状态信息。
curl -s -u Administrator:password http://127.0.0.1:8091/pools/default/tasks | jq '.[] | select(.type == "xdcr")'
接口返回的字段会因 Couchbase 版本略有差异，但通常会包含下面这些关键内容。简化后的响应示例如下：
{
"type": "xdcr",
"status": "Running",
"id": "9f8d7c6e-5b4a-4a3e-9d2c-1f0a9b8c7d6e",
"source": "travel-sample",
"target": "backup-cluster/travel-sample",
"continuous": true,
"changesLeft": 0,
"docsChecked": 48620,
"docsWritten": 48618,
"errorsSeen": 0,
"docsFailed": 0
}
除了任务接口，还可以使用 Couchbase 自带的 cbstats 工具读取 XDCR 统计项。下面的命令会输出指定 bucket 下所有 xdcr 前缀的指标，适合做更细粒度的性能分析。
cbstats -u Administrator -p password -b travel-sample 127.0.0.1:11210 xdcr
实际输出中可能包含 xdcr_changes_left、xdcr_docs_written 等指标，不同版本命名会有差异。建议先执行一次不带过滤的命令，确认当前集群暴露了哪些 xdcr 相关统计项，再决定脚本里要采集哪些字段。任务接口适合判断运行状态，统计接口适合判断积压和速率，两者配合使用才能得到完整结论。
三、常见状态值解析与排查路径
Running 是最常见但最容易误读的状态。它只说明复制任务没有被暂停，源端和目标端之间的数据同步仍在进行。如果目标端写入效率跟不上源端变更速度，changesLeft 会逐渐增大，这时候虽然状态还是 Running，实际已经处于复制延迟状态。此时应优先检查目标集群的 CPU、内存和磁盘写入能力，同时查看源和目标之间的网络延迟。
Paused 通常表示复制任务被手动暂停，例如运维窗口期间主动停止复制，或者变更了复制定义后没有重新启用。如果确认没有人工操作，需要检查是否有自动化脚本误调用了暂停接口。而 Failed 一般意味着配置错误或目标集群不可达，常见原因包括远端集群引用失效、认证信息过期、目标 bucket 不存在、版本不兼容等。
遇到 Failed 或状态异常切换，优先查看节点上的 XDCR 日志。日志位置通常在 Couchbase 的数据目录下，使用下面的命令可以快速查看最近记录。
tail -n 200 /opt/couchbase/var/lib/couchbase/logs/xdcr.log
如果日志中频繁出现认证失败或连接超时，需要回到 XDCR 复制定义中检查远端集群地址、用户名和密码是否正确。如果日志显示目标 bucket 写入失败，可以对比源端和目标端的 bucket 配置，确认是否存在内存配额不足或磁盘写入瓶颈。日志排查通常能直接定位到网络层、认证层还是存储层的问题。
四、建立状态巡检与告警指标
日常巡检建议把 status、changesLeft 和 errorsSeen 作为三个核心指标。可以在脚本中同时读取任务状态和积压数量，当状态不再是 Running，或者积压超过业务可接受阈值时输出告警。下面是一个简单的 bash 巡检脚本示例。
#!/bin/bash status=$(curl -s -u Administrator:password http://127.0.0.1:8091/pools/default/tasks | jq -r '.[] | select(.type == "xdcr") | .status') left=$(curl -s -u Administrator:password http://127.0.0.1:8091/pools/default/tasks | jq -r '.[] | select(.type == "xdcr") | .changesLeft') if [ "$status" != "Running" ] || [ "$left" -gt 100 ]; then echo "XDCR 状态异常: status=$status changesLeft=$left" fi
告警阈值不建议直接设成 0，因为异步复制本身存在短暂积压是正常现象。应该根据业务的写入速率和可接受延迟来设置，例如持续 5 分钟 changesLeft 超过 1000 才触发告警，避免误报干扰运维判断。同时要关注 docsFailed 和 errorsSeen 的增量变化，如果这些值持续增长，即使任务状态显示 Running，也需要立即排查目标端写入失败的具体原因。
将脚本加入 crontab 定时执行，或者把采集结果导入 Prometheus 等监控系统，可以形成长期趋势数据。XDCR 健康不是某个时间点的瞬时状态，而是一段时间内的连续表现。只有把状态字段和统计数据结合起来持续观察，才能在复制延迟扩大之前发现问题。
