Pika PMC 会议纪要 2026/06/26

[Mixficsol]

Pika PMC 会议纪要

项目	内容
会议日期	2026 年 6 月 26 日（周五）
会议时间	19:00 - 21:00（北京时间）
会议形式	线上会议
参会人员	PMC 成员
会议记录	TODO

---

一、议题概览

序号	议题	关联链接	状态
1	Codis-Proxy 日志清理与滚动策略增强	—	讨论中
2	Codis 切主不比对老主位点，写入高时切主丢数据 + 老主被迫全量重做	—	讨论中
3	高低配混部主从同步追不上的优化方案	—	讨论中
4	unstable 主从同步（rsync 全量同步）写文件路径疑似存在 bug	—	讨论中

说明：本次议题来自现场反馈，部分技术结论已结合当前代码核对，下方在对应处标注「代码核对」。

---

二、议题详细讨论

议题 1：Codis-Proxy 日志清理与滚动策略增强

• 背景：
  • 现场反馈 codis-proxy 目前不能自动清理日志，无法设置「保留天数」或「保留个数」，长期运行会导致日志文件持续堆积、占满磁盘。
  • 日志只能按日期切分，不支持按数据量（文件大小）切分。
• 代码核对：
  • 日志滚动实现位于 codis/pkg/utils/log/rolling.go，切割依据是 time.Now().Format(...) 的时间后缀（支持 Monthly / Daily / Hourly 等按时间维度滚动，见 rolling.go:35-53）。
  • 写文件仅以 O_CREATE|O_WRONLY|O_APPEND 打开当前时间片对应文件（rolling.go:60），未发现任何 max_age / max_backups / rotate_size 之类的清理或按大小切割逻辑。
  • 结论：现场反馈属实 —— 当前实现「按时间滚动，不按大小切割，不自动清理旧日志」。
• 方案要点：
  • 在 rolling.go 中新增日志保留策略：
    • 保留天数（log-keep-days）：超过 N 天的历史日志文件自动删除。
    • 保留个数（log-keep-files）：仅保留最近 N 个滚动文件。
  • 评估是否补充「按文件大小切割」能力（size-based rolling），与现有时间切割共存。
  • 切割/清理动作放在后台异步执行，避免阻塞写日志路径。
• 讨论要点：
  • 保留策略默认值（建议：保留天数 7 天 / 保留个数 30）。
  • 是否同时支持「按大小 + 按时间」双触发滚动，还是二选一配置。
  • 是否直接复用社区成熟方案（如 lumberjack）降低维护成本。
• 结论 / Action Items：
  • TODO

---

议题 2：高低配混部下主从同步追不上的优化方案

• 背景：
  • 现场存在「高低配置混部」的 Pika 集群：从节点配置低，CPU / 磁盘长期 100%，binlog 同步追不上主节点。
  • 现场提出三个方向求助：① slave 用 progressive-compact、master 用 full-compact 是否可行、是否会因 SST 不一致导致同步异常；② 从节点 compaction filter 是否值得优化以提升同步速度；③ 参数调优。
• 代码核对（重要：纠偏）：
  • 主从 SST 文件本就不要求一致：Pika 主从基于 binlog 逻辑复制，而非物理文件复制。主从各自独立做 compaction，SST 文件布局天然不同，因此「slave 用某策略、master 用另一策略」不会因 SST 文件不一致导致同步异常——这一点可以打消顾虑。
  • compaction-strategy 实际取值：代码中该配置仅支持 full-compact / obd-compact，否则回落 none（src/pika_conf.cc:339-345,891-897）。当前仓库中并不存在 progressive-compact 这个取值，对 progressive 关键字检索无任何命中。
  • 现场给出的以下参数在当前代码中均不存在，配置后不会生效，需移除或确认是否为目标分支特性：
    • compaction-strategy = progressive-compact（取值不支持）
    • progressive-compact-interval
    • progressive-compact-max-files
    • progressive-compact-max-time-ms
  • 确认存在、可用于调优的参数（均已在 conf/pika.conf / pika_conf.cc / pika_conf.h 核对）：
    • disable-auto-compactions
    • level0-file-num-compaction-trigger / level0-slowdown-writes-trigger / level0-stop-writes-trigger
    • max-background-flushes / max-background-compactions / max-background-jobs / max-subcompactions
    • sync-binlog-thread-num / sync-thread-num / sync-window-size
    • max-cache-statistic-keys / small-compaction-threshold
    • compression
  • compaction filter：实现位于存储层（src/storage/src/{strings,base,lists,zsets}_filter.h），从实现形态看是 DB 侧统一 compaction 过程触发，未见「仅主库启用、从库禁用」的角色判断。从节点同样会跑 compaction filter，因此「优化从节点 compaction filter 以减轻从库负载」方向值得探索（如降低从库 filter 的清理频率/开销）。
• 针对三个问题的初步意见：
  1. slave/master 用不同 compact 策略是否可行：可行，逻辑复制下不会因 SST 不一致导致同步异常。但 progressive-compact 取值当前不存在，需先确认该特性是否在目标分支落地（关联议题：渐进式 Compaction PR）。
  2. 从节点 compaction filter 是否值得优化：值得。从库照样执行 filter，针对低配从库降低 filter 开销有助于把 CPU/磁盘资源让给同步。
  3. 参数调优：方向合理（关闭自动 compact、放宽 L0、提升同步并行度、从库关压缩），但需剔除上述不存在的 progressive 参数，仅保留已确认存在的参数。
• 现场给出的参数草案（需按上文剔除不存在项后再下发）：

  # 核心：关自动 compact + 放宽 L0
  disable-auto-compactions = true
  # compaction-strategy = progressive-compact   # ❌ 当前不支持该取值，需确认特性是否落地
  # progressive-compact-interval = 60            # ❌ 不存在
  # progressive-compact-max-files = 2            # ❌ 不存在
  # progressive-compact-max-time-ms = 2000       # ❌ 不存在
  level0-file-num-compaction-trigger = 40
  level0-slowdown-writes-trigger = 60
  level0-stop-writes-trigger = 80
  # 减少 compaction 资源占用
  max-background-flushes = 2
  max-background-compactions = 2
  max-background-jobs = 4
  max-subcompactions = 1
  # 增加同步并行度
  sync-binlog-thread-num = 4
  sync-thread-num = 6
  sync-window-size = 30000
  # 关闭统计收集 / 小压缩
  max-cache-statistic-keys = 0
  small-compaction-threshold = 0
  # 从节点不需要压缩
  compression = none

• 讨论要点：
  • 确认 progressive-compact 特性在哪个分支/PR，是否可供从库使用。
  • 从库 compaction filter 的具体优化点与收益评估。
  • 低配从库的根因：是 compaction 抢资源，还是单纯磁盘/CPU 不足？必要时建议从库配置升级。
  • 上述参数在低配从库的实测同步追赶效果。
• 结论 / Action Items：
  • TODO

---

议题 3：unstable 主从同步（rsync 全量同步）写文件路径疑似存在 bug

• 背景：
  • 复核 unstable 分支主从同步机制时，发现疑点集中在**全量同步（rsync 传 master 的 dump/checkpoint 文件，会落 SST）**这一路径，而非 binlog 增量回放。
  • Pika 主从分两段：①全量同步——rsync 传 master 的 dump/checkpoint 文件，会写 SST；②增量同步——主库写 binlog、从库回放命令，不直接写 SST，走正常写入路径。所以「主从同步导致 SST 损坏」这类担忧，主要矛头应指向 rsync 全量同步，而非 binlog 增量回放。
• 代码核对（疑点一）：RsyncWriter 用 O_APPEND + write() 写文件，忽略传入的 offset
  • 位置：include/rsync_client.h:113-136、调用点 src/rsync_client.cc:242。
  • 构造函数 open(filepath.c_str(), O_RDWR | O_APPEND | O_CREAT, 0644)（rsync_client.h:115）—— 用了 O_APPEND。
  • Write(uint64_t offset, size_t n, const char* data) 内部用 write(fd_, ptr, left) 而非 pwrite()（rsync_client.h:123），循环里 offset += done（rsync_client.h:133）只是个局部变量自增，对 O_APPEND 无效——O_APPEND 语义下每次 write 都强制写到文件当前末尾，传入的 offset 被完全忽略。
  • 客户端调用：writer->Write((uint64_t)offset, ret_count, resp->file_resp().data().c_str())（rsync_client.cc:242）把 offset 传进去了，但被上述实现忽略。
  • 后果：纯顺序、空文件、且全程无中断时不暴露（顺序追加恰好等价于顺序写入）；但只要出现以下任一情况就可能 corrupt：
    • 断点续传：上次 slave 同步到一半崩溃，留下一个部分文件；下次同步 RsyncWriter 以 O_APPEND 打开，新数据会追加到旧文件末尾，而不是从 offset 0 覆盖。
    • 超时重传：某个 chunk 的请求超时，但 server 其实已经把数据发出去了一部分；客户端是收到响应才写，所以重传本身一般不会重复写——但若上层逻辑未来改为多 chunk 并发，就会乱序追加。
    • 文件已存在：dbsync 目录里残留同名旧文件时，追加而非覆盖。
  • 可能产生：文件空洞 / 重复数据 / checksum 异常 / corrupt SST。
• 代码核对（疑点二）：rsync 缺少 chunk 级 checksum 校验
  • 位置：include/rsync_server.h:105-118、src/rsync_server.cc:201-219、src/rsync_client.cc:242。
  • server 端 RsyncReader::Read(...) 的 checksum 出参全程未被赋值（初值为空串 ""，rsync_server.h:105-118 内只 memcpy 数据、设置 bytes_read/is_eof，从不计算 checksum）。
  • 但 server 仍把它塞进响应：file_resp->set_checksum(checksum)（rsync_server.cc:216）——实际塞进去的是空串。
  • 客户端 rsync_client.cc:242 收到响应后完全没有校验 resp->file_resp().checksum()，直接 writer->Write(...)。
  • 后果：即使网络偶发把某个 chunk 的数据弄坏（TCP checksum 也有一定概率漏检），客户端也照写不误，缺少第二层防护。
• 小结：以上两点不能 100% 断定就是某次 corrupt SST 的根因，但是全量同步路径上两个确凿的实现缺陷，完全可能在网络抖动 + 断点续传场景下造出 corrupt SST。
• 讨论要点 / 待办（TODO）：
  • 确认上述路径在「网络抖动 + 断点续传」场景下能否复现 corrupt SST（构造中断 + 残留文件再续传的回归用例）。
  • 修复方向一：去掉 O_APPEND，Write 改用 pwrite(fd_, ptr, left, offset) 按真实 offset 定位写入。
  • 修复方向二：补齐真实的 chunk checksum——server RsyncReader::Read 计算 checksum，client 写前比对，不一致则重传该 chunk。
  • code review 待跟进。
• 结论 / Action Items：
  • TODO

议题 4：Codis 切主不比对老主位点，写入高时切主丢数据 + 老主被迫全量重做

• 背景（现场反馈）：
  • 昨日在写入 QPS 较高的情况下做切主（promote），出现切主失败现象。
  • 怀疑链路：binlog-file-size 调得偏小 → binlog 滚动快、老文件被 purge → 老主想增量 slaveof 新主时位点对不上 → 触发全量同步；老主只能整库重做（dump + rsync）。
  • 更担心的是数据丢失风险：主动切主时，Codis 只会从从节点里挑数据最新的作为新主，不会跟老主自身的数据/位点比对。写入高时从库不一定追平主库，新主可能比老主少一段数据；切主后老主又被强制重做，那段未同步的数据就丢了。
  • 现场疑问：切主时主库会先设 readonly、等从库位点追上才切吗？→ 不会，主动切主是直接选一个从节点 slaveof no one 提升为主。
• 代码核对（已逐条坐实）：
  • ① 选主只在从节点里挑、按 binlog 位点选最新，且明确跳过老主：Group.SelectNewMaster()（codis/pkg/models/group.go:29-58）循环里 index == 0（老主）直接 continue 跳过（group.go:34），其余从节点先比 DbBinlogFileNum、再比 DbBinlogOffset，选位点最大的从节点（group.go:41-50）。→ 现场判断属实：只在从节点间比位点选最新，从不与老主位点比对。
  • ② 自动切主路径连「新主是否追上」都没校验：trySwitchGroupMaster（codis/pkg/topom/topom_group.go:461-476）选完新主后，本该校验可用性的 isAvailableAsNewMaster（检查 master_link_status == down，即全量同步未完成）那段被 // TODO liuchengyu check new master is available 整段注释掉了（topom_group.go:469-473）。isAvailableAsNewMaster 函数虽然实现了（topom_group.go:478-499），但未被调用。
  • ③ 主动切主（GroupPromoteServer）全程无位点比对、无 readonly、无等待追平：GroupPromoteServer（topom_group.go:201 起）入参直接是人工/调用方指定的 addr，流程 ActionPrepared 阶段（topom_group.go:269-306）直接把 g.Servers[index] 当新主，调 promoteServerToNewMaster(slice[0].Addr, ...)（topom_group.go:305）执行 slaveof no one（codis/pkg/utils/redis/client.go:331），没有任何"先 readonly→等从库位点追平→再切"的环节。
  • ④ Pika 没有真正可用的写保护（readonly）：存在 slave-read-only 配置项（src/pika_conf.cc:119、include/pika_conf.h:404-406），但全仓 src/*.cc 中没有任何写命令路径用它来拦截写（grep 零命中）。→ 印证现场说法：Pika 实际没有 readonly 写开关，要让老主停写只能 slaveof 一个不存在的实例。
  • ⑤ 位点对不上即全量同步 —— 3.5.6 起行为坐实：PikaReplServerConn::TrySyncOffsetCheck（src/pika_repl_server_conn.cc:172-217）：
    • 若老主位点比新主还大（老主多写了数据）→ 返回 kSyncPointLarger（pika_repl_server_conn.cc:189-196），增量 TrySync 失败 → 老主无法增量挂到新主下。
    • 若从库请求的 binlog 文件已被 purge → 返回 kSyncPointBePurged、日志 "binlog has been purged, may need full sync"（pika_repl_server_conn.cc:198-203）→ 触发全量同步。这正对应「binlog-file-size 太小 → 文件滚动快被清 → 全量」的现场怀疑。
  • 结论：现场描述的两个核心问题均属实——(a) 切主只挑从节点最新位点、不与老主比对，写入高时新主可能落后老主，存在丢数据风险；(b) 老主位点对不上后只能全量重做。
• 方案讨论（现场提出 + 初步意见）：
  • 加位点比对阈值（现场建议）：切主前比对「拟选新主」与「老主」的位点差，差值在阈值内才允许切；超过阈值给出告警/确认。位点比对本身不复杂（SelectNewMaster 已经在用 DbBinlogFileNum/DbBinlogOffset，可复用）。
  • 难点：master 持续有写流量，要求新主实时追平老主不现实；且 Pika 无 readonly，无法先冻结写再切。折中思路：
    • (a) 可控停写窗口：切主前对老主 slaveof 不存在实例（或新增真正生效的 readonly 开关）冻结写入，再等新主位点追平到阈值内、最后 slaveof no one，把丢数据窗口压到最小。
    • (b) 切主前置校验：恢复/启用被注释掉的 isAvailableAsNewMaster 校验，至少保证新主 master_link_status != down（全量已完成）才允许被选为新主。
    • (c) 位点差阈值可配 + 强制确认：新主落后老主超过阈值时，默认拒绝自动切主、主动切主需显式 force，避免「静默丢数据」。
• 讨论要点：
  • 给 Codis 切主增加「新主 vs 老主」位点差阈值校验（默认值待定，建议可配）。
  • 为 Pika 补一个真正生效的 readonly 写开关，替代「slaveof 不存在实例」这种 trick。
  • 启用/补全 isAvailableAsNewMaster（去掉 topom_group.go:469-473 的 TODO 注释），切主前校验候选新主同步状态。
  • binlog-file-size 与 binlog 保留策略的推荐配置，降低切主即全量的概率。
  • 主动切主与自动（sentinel HA）切主两条路径都要覆盖上述校验。
• 结论 / Action Items：
  • TODO

---

---

三、下一步计划

序号	事项	负责人	预计完成时间
1	Codis-Proxy 日志保留策略（天数/个数）设计与实现	TODO	TODO
2	Codis 切主位点比对阈值 + Pika readonly 写开关 + 启用候选新主校验	TODO	TODO
3	低配从库同步追赶参数实测 + compaction filter 优化	TODO	TODO
4	rsync 全量同步 O_APPEND→pwrite 修复 + chunk checksum 校验补齐	TODO	TODO

---

四、下次会议安排

• 时间：TODO
• 议题预告：
  • 上述 Action Items 进展同步
  • progressive-compact 特性落地情况确认
  • rsync 全量同步 corrupt SST 复现与修复进展
  • 其他待定议题

---

本文档由会议记录人整理，部分技术结论已结合当前代码核对（标注「代码核对」处）。如有遗漏或错误，请及时反馈修正。