PostgreSQL 复制与高可用系列（四）：逻辑复制深度实战——跨版本迁移、数据分发与冲突处理 前三期我们完成了物理流复制从理论到实战的全链路学习，掌握了高可用架构的基石。 但物理复制有一个天然局限：它复制的是整个数据库集群，无法“选择性地同步几张表”，也不能在主备之间做异构同步（比如 12 → 17 跨大版本）。 第四期将聚焦逻辑复制——这张灵活的“手术刀”，为您打开数据同步的全新维度。 一、逻辑复制是什么？ 1.1 定义与定位 逻辑复制是一种基于数据对象的复制标识（通常是主键）来复制数据对象及其更改的方法。这里使用“逻辑”一词来与物理复制（基于块地址和逐字节复制）加以区分——物理复制关注的是磁盘上数据块的变化，而逻辑复制关注的是数据的语义变化（插入、更新、删除）。 核心特点：PostgreSQL 同时支持物理复制和逻辑复制两种机制，两者可以并行运行，不互斥。这给了架构设计极大的灵活性。 1.2 架构：一次 WAL 的两面使用 逻辑复制的架构与物理流复制类似，同样由
PostgreSQL 复制与高可用系列（三）：同步与异步复制工程实践——RPO/RTO 量化与性能权衡 第二期我们亲手搭建了流复制集群，验证了异步与同步两种模式的基本行为。 但生产环境中，“选同步还是异步”从来不是一道非黑即白的选择题——它涉及到业务对数据丢失的容忍度、对写入延迟的敏感度、网络基础设施的可靠性，以及预算与运维成本的综合权衡。 第三期将系统分析同步与异步复制的工程取舍，并给出可量化的决策模型。 一、开篇：一个真实的生产事故 某互联网公司采用 PostgreSQL 异步流复制搭建了主备高可用架构。某日凌晨，主库所在物理机因 SSD 损坏而宕机，系统按预案自动切换到备库。恢复服务后才发现，故障前 5 秒内写入的一笔高价值订单数据永远丢失了——因为该事务的 WAL 记录尚在主库内存中，未传输到备库。 事后分析，RPO 约等于 5 秒。对于该公司的主力业务，RPO
PostgreSQL 复制与高可用系列（二）：物理流复制实战——从零搭建主从集群 第一期我们搭建了知识框架，认识了 WAL 基石、物理复制与逻辑复制的差异、同步与异步的血肉权衡。 第二期不再纸上谈兵——我们将动手搭建一个完整的流复制主从集群，逐行验证每个配置参数的实际效果。 一、搭建前的脑内基建 物理流复制的核心机制是将数据变更按字节级别复制到备库，这背后涉及三个核心进程的协作。主库上的 walsender 持续向外发送 WAL 流，并为每个备库分配一个独立进程；备库上的 walreceiver 接收传来的 WAL 数据；后台的 startup 进程将这些数据重放到数据文件中。当备库配置为 hot_standby =
PostgreSQL 复制与高可用系列（一）：从单点到集群，构建生产级数据基石 PostgreSQL 已成为无数企业核心系统的首选数据库，但单机部署始终是一个绕不开的问题：单点就是风险。当硬件故障、网络波动或人为误操作不期而至时，缺乏高可用架构的应用将面临不可预测的停机时间，甚至数据丢失。 本系列旨在系统梳理 PostgreSQL 复制与高可用技术，从原理到实践，从基础到进阶。作为开篇，本文将聚焦于核心概念、技术演进与关键原理，帮助读者建立完整的知识框架，为后续的动手实践打下坚实基础。 一、为什么要谈复制与高可用？ 1.1 核心驱动力 在生产环境中建设高可用体系，根本目的是满足两个关键指标： RPO（Recovery Point Objective）：能容忍的最大数据丢失量，即灾难发生后，最多能接受丢失多长时间的数据。 RTO（Recovery Time Objective）：能容忍的最大恢复时间，即从故障发生到服务恢复，允许经过多长时间。 这两个指标直接决定了架构设计的走向。追求 RPO=0（零数据丢失）往往意味着采用同步复制，而这可能牺牲写入性能；追求极低 RTO
PostgreSQL 存储与索引系列（四）：高级调优与内核机制——并发、日志、内存与分区 这是系列第四期，也是收官之篇。我们将深入 PostgreSQL 的高级特性与性能调优核心：并发控制与锁、事务隔离级别、预写日志（WAL）与检查点、关键内存参数调优，以及分区表的维护策略。结合前三期的存储和索引知识，你已具备构建高可用、高性能 PostgreSQL 系统的完整视图。 1. 并发控制与锁机制：避免踩踏的艺术 PostgreSQL 采用 MVCC（多版本并发控制） 实现读写不互斥，读不阻塞写，写不阻塞读。但某些操作（如 DDL、外键维护、显式锁）仍需传统锁机制。理解锁层级是避免死锁和性能瓶颈的前提。 表级锁模式（从弱到强） ACCESS SHARE：SELECT 获取，与 ROW EXCLUSIVE
PostgreSQL 存储与索引系列（三）：查询优化实战——执行计划、统计信息与反模式诊断 这是系列第三期，聚焦查询优化。我们将深入解读执行计划，学习如何利用统计信息和 ANALYZE 做出正确决策，识别并避免常见的慢查询反模式，并借助 pg_stat_statements 等工具定位真实瓶颈。前两期关于存储页、可见性映射和各类索引的知识，将在这里融会贯通。 1. 执行计划：读懂 PostgreSQL 的每一步 EXPLAIN 是分析查询性能的首要工具。加上 ANALYZE 会真实执行并返回实际行数、耗时、内存等；加上 BUFFERS 可查看缓存命中情况；加上 VERBOSE 输出额外细节。 核心节点类型
PostgreSQL 存储与索引系列（二）：索引的艺术——从 B-tree 到 BRIN 的全景指南 这是系列第二期，聚焦 PostgreSQL 的索引世界。我们会逐一拆解 B-tree、Hash、GiST、GIN、BRIN 等索引的内部机理与适用场景，并介绍部分索引、表达式索引等高级特性。结合上一期关于存储页、ctid、可见性映射的知识，你将对索引如何加速查询、何时失效、如何选型有系统的认知。 0. 索引基础：快速回顾 索引本质：一种有序的“目录”结构，通过少数列的值快速定位表中行的物理位置（ctid：页号+偏移）。 访问路径：索引扫描 → 获取 ctid → 回表（除非是仅索引扫描，需借助
PostgreSQL 存储与索引系列（一）：数据在磁盘上如何安放——表、页、TOAST 与 VACUUM 这是系列文章的第一期，专注 PostgreSQL 的存储核心：表与行的组织、磁盘页结构、大字段的 TOAST 技术，以及不可或缺的 VACUUM 机制。后文还会介绍表分区，为下一期索引专题打下坚实基础。 1. 从逻辑表到物理文件 在 PostgreSQL 中，每个用户表都对应着磁盘上的一个或多个文件。默认情况下，一张表的数据存储在以表 OID 命名的文件中（位于 $PGDATA/base/）。当表或索引超过
PostgreSQL 事务与并发系列 · 第五期 实战调优：事务的常见陷阱与最佳实践 前四期我们深入了 MVCC、锁、隔离级别与序列化异常。本期将把这些知识落地到生产环境的日常运维与开发中，剖析长事务、空闲事务、表膨胀、死锁超时等真实痛点，并提供一套可立即上手的监控、报警与优化方案。 一、长事务：性能与运维的头号杀手 1.1 为什么长事务如此危险？ 阻止 VACUUM 清理：长事务持有的快照会让所有在它之后产生的死亡元组都无法被清理，导致表与索引持续膨胀。 事务 ID 回卷风险：事务 ID 是 32 位环状空间，长事务可能导致
PostgreSQL 事务与并发系列 · 第四期 事务隔离级别深度测试与序列化异常 前三期我们构建了从 MVCC 到锁机制的完整知识体系。本期将聚焦三种隔离级别的实际行为边界，通过可复现的案例演示“不可重复读”“幻读”以及最隐蔽的“写偏斜（Write Skew）”，同时揭开 PostgreSQL 可串行化快照隔离（SSI）的神秘面纱。 一、隔离级别速览与默认行为回顾 PostgreSQL 支持三种隔离级别（READ UNCOMMITTED 实际等同于 READ COMMITTED）： 隔离级别 脏读