sync_full不是Redis内置INFO指标，而是外部工具通过解析日志（如FULLRESYNC）或自定义埋点统计的事件型指标，原生不记录历史次数。
Redis 的 sync_full 计数器本身不可直接监控 —— 它不是 Redis 内置的 INFO 指标，而是由客户端（如 redis-shake、自研同步工具）或运维脚本自行统计的逻辑指标。
为什么 sync_full 不在 INFO replication 里
Redis 原生命令 INFO replication 中只暴露以下关键同步指标：
-
connected_slaves：当前连接从节点数 -
master_repl_offset：主节点当前复制偏移量 -
slaveX:ip=..., port=..., state=..., offset=...：各从节点状态与偏移量 -
repl_backlog_active、repl_backlog_size、repl_backlog_first_byte_offset：复制积压缓冲区信息
但 sync_full（全量同步发生次数）不在此列。它属于“事件型”指标 —— 只有在 PSYNC 触发全量同步时才发生，且 Redis 不记录历史次数。你看到的 sync_full 通常来自外部工具日志解析或 Prometheus exporter 的自定义埋点。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何在生产中实际获取 sync_full 计数
真正可行的方式只有两种，取决于你用什么做同步：
- 如果你用
redis-shake：它会在日志中明确打印full sync start和full sync finished，配合grep -c "full sync start"或采集到 Loki/ELK 即可统计。注意：redis-shake的sync_full是它自己发起的全量迁移次数，和 Redis 主节点是否触发原生全量无关。 - 如果你依赖原生主从（
replicaof）：需监听主节点的redis-server日志（开启verbose或notice级别），搜索关键词"FULLRESYNC"—— 每次出现即代表一次全量同步启动。例如：12345:M 05 Sep 21:12:33.456 * Slave 192.168.10.22:6379 asks for synchronization<br>12345:M 05 Sep 21:12:33.457 * Full resync requested by slave 192.168.10.22:6379<br>12345:M 05 Sep 21:12:33.458 * Starting BGSAVE for SYNC with target: disk
这三行中的第二行就是可靠信号。 - 不要依赖
sync_partial_ok/sync_partial_err推算：这两个指标只反映增量同步是否成功，无法反推全量是否发生；一次全量后可能长期只有增量，它们的值不会重置或关联。
容易被忽略的关键点
生产中最常踩的坑是把「全量同步发生」和「全量同步完成」混淆：
-
FULLRESYNC日志只表示主节点决定发起全量，不代表从节点一定能成功加载 RDB —— 若从节点磁盘满、内存不足、RDB 校验失败，会静默断连，此时sync_full已计数但数据未就绪。 - 主节点重启必然触发
FULLRESYNC（因run_id变更），但若从节点配置了replica-serve-stale-data no，它会在全量期间拒绝读请求，监控时需同时看从节点的loading状态（INFO stats中的loading字段为1）。 - 云数据库（如阿里云 ApsaraDB Redis）通常屏蔽底层
FULLRESYNC日志，此时必须依赖控制台的「同步延迟」图表 + 「同步状态」API（如DescribeReplicationStatus）间接判断 —— 突然跳升的延迟峰值 + 状态变为SYNCING，大概率对应一次全量。
真正的难点不在采集，而在归因：一次 FULLRESYNC 是因为从节点重启？网络闪断超时？还是 repl-backlog-size 太小导致 offset 被覆盖？必须结合 repl_backlog_histlen、从节点断连时间、网络监控一起看。
