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、从节点断连时间、网络监控一起看。