morling.dev -- Blog
·
Postgres 复制槽：确认刷新 LSN 与重启 LSN
💡
原文英文，约2500词，阅读约需9分钟。
📝
内容提要
Postgres中的复制槽用于跟踪消费者读取复制流的进度，包含两个LSN属性：restart_lsn和confirmed_flush_lsn。restart_lsn表示消费者可能需要的最旧WAL地址，confirmed_flush_lsn是消费者确认接收数据的最新LSN。这两者的区别对故障排除和优化WAL保留非常重要。
🎯
关键要点
- Postgres中的复制槽用于跟踪消费者读取复制流的进度，包含两个LSN属性：restart_lsn和confirmed_flush_lsn。
- restart_lsn表示消费者可能需要的最旧WAL地址，confirmed_flush_lsn是消费者确认接收数据的最新LSN。
- confirmed_flush_lsn是逻辑槽消费者确认接收数据的地址，数据在此LSN之前的事务不再可用。
- restart_lsn是消费者可能需要的最旧WAL地址，防止在检查点期间被自动删除。
- 在并发事务中，数据库不能立即修剪所有早期的WAL部分，直到所有相关事务都已提交并被消费者确认。
- 逻辑复制的消费者不能依赖接收到的事件的LSN严格递增，只有提交LSN和事件LSN的元组是严格递增的。
- Postgres 14版本开始支持正在进行的事务的逻辑复制，可以减少大事务保留的WAL量。
❓
延伸问答
Postgres中的复制槽有什么作用？
复制槽用于跟踪消费者读取复制流的进度，确保在重启后可以安全恢复。
restart_lsn和confirmed_flush_lsn有什么区别？
restart_lsn是消费者可能需要的最旧WAL地址，而confirmed_flush_lsn是消费者确认接收数据的最新LSN。
如何查询Postgres中的复制槽状态？
可以通过查询pg_replication_slots视图来查看复制槽的状态，包括restart_lsn和confirmed_flush_lsn。
为什么需要保留restart_lsn？
restart_lsn确保在并发事务中，数据库不会立即删除仍可能被消费者需要的WAL部分。
Postgres 14版本引入了什么新特性？
Postgres 14开始支持正在进行的事务的逻辑复制，减少大事务保留的WAL量。
在逻辑复制中，消费者如何处理并发事务？
消费者不能依赖接收到的事件的LSN严格递增，只有提交LSN和事件LSN的元组是严格递增的。
➡️
