ElectricSQL 复制槽冲突问题与滚动部署解决方案

背景与问题分析

在 ElectricSQL 项目中，PostgreSQL 复制槽(replication slot)的管理是一个关键的技术挑战。当前实现中使用了固定名称的发布槽，这导致了两个主要问题：

1. 滚动部署困难：无法同时运行新旧版本的服务实例，因为它们的复制槽名称冲突
2. 崩溃恢复问题：当 Electric 实例崩溃时，可能无法清理其发布槽，导致新实例无法正常接管

技术解决方案探讨

临时复制槽方案

一种可行的解决方案是采用"持久槽+临时槽"的双槽策略：

1. 系统首次运行时创建持久复制槽
2. 每次建立复制连接时，从持久槽克隆出一个临时随机命名的槽
3. 连接关闭后，PostgreSQL 自动清理临时槽

这种方案的优势在于：

• 避免了槽名称冲突
• 自动处理槽清理
• 保留了复制进度(LSN)

但需要注意持久槽的独占访问问题，特别是在需要推进LSN时。

基于咨询锁的滚动部署方案

更完整的解决方案结合了咨询锁(advisory lock)机制：

1. 启动流程：

   • Electric 启动时检查持久复制槽是否存在
   • 不存在则创建并获取咨询锁，标记为"active"状态
   • 存在则持续尝试获取锁，标记为"ready"状态

2. 部署流程：

   • 编排系统检测到新实例处于"ready"状态
   • 关闭旧实例释放锁
   • 新实例获取锁转为"active"状态

3. 并发控制：

   • 咨询锁确保同一时间只有一个活跃消费者
   • 即使多个实例同时启动也能保证唯一性

架构考量与扩展性

状态持久化与无状态部署

方案支持两种部署模式：

1. 有状态部署：

   • 实例间共享持久存储
   • 新实例能完全继承旧实例的状态
   • 形状(shape)无需重建，实现无缝切换

2. 无状态部署：

   • 新实例重建所有形状
   • 复制流从持久槽位置继续
   • 可能有一定延迟但保证最终一致性

水平扩展支持

该架构也为未来水平扩展奠定了基础：

• 每个Electric实例可配置独立槽名
• 支持形状的细粒度迁移
• 为负载均衡和容量扩展提供可能

实现建议与最佳实践

1. 健康检查设计：

   • 区分"starting"、"ready"和"active"状态
   • 编排系统根据状态决策流量切换

2. 监控与告警：

   • 监控复制延迟
   • 槽清理异常告警
   • 锁争用情况监控

3. 部署策略：

   • 蓝绿部署支持
   • 金丝雀发布兼容
   • 自动故障转移

未来优化方向

1. 形状热迁移：

   • 支持形状的逐个迁移
   • 实现负载的动态平衡

2. 复制优化：

   • 增量快照技术
   • 并行复制支持

3. 存储效率：

   • 压缩复制数据
   • 智能清理策略

这套方案不仅解决了当前的复制槽冲突问题，还为ElectricSQL的高可用部署和未来扩展奠定了坚实基础。