阻止切换以保护复制槽
内容提要
PlanetScale 为 Postgres 引入逻辑复制槽保护机制。逻辑槽记录 WAL 变更流供下游消费，若副本未同步槽即被提升为主库，下游会丢数据。因此 PlanetScale 检测并告警槽配置错误，阻止会丢失槽的切换，等待槽就绪。用户需将槽设为 failover=true，在控制台登记槽名，并开启 hot_standby_feedback 和 sync_replication_slots。
延伸解读
逻辑复制槽：下游数据不丢的关键
逻辑复制槽将 WAL 解码为行级变更事件，供搜索索引、分析工具等下游消费。若副本未同步槽就被提升为主库，下游会丢失自上次确认后的所有事件，或需重新快照。PlanetScale 阻止此类切换，避免数据丢失。
正确配置槽的步骤
创建槽时需设置 failover = true，并在控制台 Clusters > Parameters > Logical slot name 登记槽名。同时开启 hot_standby_feedback 和 sync_replication_slots。已有槽可修改，但若正被消费会挂起，需终止消费者。
开启参数的代价
hot_standby_feedback 开启后，副本会告知主库其仍读取的旧行，从而固定 vacuum horizon，可能导致主库膨胀，长时间运行的事务会加剧问题。sync_replication_slots 依赖前者，否则 vacuum 可能使槽副本失效。默认关闭适合无 CDC 消费者的数据库。
不处理的后果
若忽略告警，PlanetScale 会在宽限期后允许被阻止的切换继续。但下游消费者可能丢失更新，且没有可信的恢复位置。因此，及时配置槽并开启相关参数是保障下游数据完整性的必要措施。
Q&A
PlanetScale 在什么情况下会阻止数据库切换？
当逻辑复制槽未同步到副本时，PlanetScale 会阻止计划内的切换（如调整大小、参数更改或维护），以防止下游应用丢失数据。
逻辑复制槽在 Postgres 中起什么作用？
逻辑复制槽将 WAL 解码为逐行变更事件，通常发送给外部订阅者，如搜索索引、分析工具和队列。
如果副本没有同步逻辑复制槽就被提升为主库，会有什么后果？
下游消费者会丢失自上次确认以来的所有事件，或者停滞直到重新快照，导致数据丢失。
如何让逻辑复制槽在 PlanetScale 上支持故障转移？
创建槽时设置 failover = true，例如：SELECT pg_create_logical_replication_slot('analytics_cdc', 'pgoutput', false, false, true); 对于已有槽，使用 ALTER_REPLICATION_SLOT analytics_cdc (FAILOVER true); 但需注意如果槽正在被消费，修改会挂起，需终止消费者。
在 PlanetScale 控制台中如何登记逻辑复制槽名称？
在控制台的 Clusters > Parameters > Logical slot name 下添加所有必需的槽名称，每个新槽都需要重复此步骤。
为什么需要开启 hot_standby_feedback 和 sync_replication_slots 参数？
hot_standby_feedback = 'on' 保持书签副本有效以便提升后使用；sync_replication_slots = 'on' 指示 Postgres 将槽状态复制到副本。两者需同时开启以确保槽在提升后可用。
开启 hot_standby_feedback 和 sync_replication_slots 有什么潜在代价？
hot_standby_feedback 开启会固定主库的 vacuum horizon，可能导致主库膨胀，且副本上的长事务可能引发问题；sync_replication_slots 单独开启而 hot_standby_feedback 关闭时，副本可能在 vacuum 运行后失效。
