复制槽与连接管理

• XID 的 32 位与回卷
• 环形比较与新旧颠倒
• 冻结机制

PostgreSQL 的事务 ID（XID）是 32 位无符号整数，约 42 亿个。事务 ID 的比较不是按大小，而是按以 2^31 为模的环形范围（"在过去 2^31 内"还是"在未来 2^31 内"）。当长时间运行超过 2^31 个事务后，环形比较会让"很旧"的 XID 看起来"在未来"，导致新旧颠倒、可见性判断错误。冻结机制：把老事务的 XID 置为 FrozenTransactionId（特殊值 2），它永远比任何真实 XID 旧，因此该行"永久可见"于所有事务，VACUUM 可安全回收该 XID 之后的空间。冻结让老版本不再依赖具体 XID，从而安全处理回卷。

回卷是 XID 32 位空间的根本风险。冻结把"可见性判定"从"与具体 XID 比较"变为"与 FrozenTransactionId 比较"，使老版本永久可见，VACUUM 才能安全推进以便回收 XID。这是 MVCC 可见性实现的关键。

• autovacuum_freeze_max_age 触发
• anti-wraparound VACUUM
• 不可取消的原因

autovacuum_freeze_max_age（默认 2 亿）是触发"为了防回卷（anti-wraparound）的自动 VACUUM"的阈值：当数据库中某表的最老未冻结事务年龄（age）超过该值，autovacuum 会强制对该表执行 VACUUM（freeze）以回收 XID。若 age 达到 20 亿（接近 2^31），数据库会进入"拒绝新事务"的防护状态。防回卷 VACUUM 不能被取消（包括 pg_cancel_backend）是因为：若取消，回卷风险将积累到数据库不可用（XID 耗尽拒绝服务），系统必须保证该 VACUUM 完成以防灾难。只能等待其完成，或通过降低其 IO 影响（如 autovacuum_cost_limit）减少对业务的影响。

anti-wraparound VACUUM 是数据库的"保命"操作，必须执行，故不可取消。理解其不可取消性，运维应主动监控 age 提前触发，避免被动。

• age(datfrozenxid) 监控
• mxid_age(datminmxid) 监控
• 应急与根治措施

监控 XID 消耗用 pg_database：age(datfrozenxid) 返回该库最老未冻结事务的年龄（当前 XID 与 datfrozenxid 之差），mxid_age(datminmxid) 返回多事务 ID（multixact）的年龄。这两个值接近 2 亿（autovacuum_freeze_max_age）时触发防回卷 VACUUM，接近 20 亿则数据库拒绝新事务。应急措施：立即执行 VACUUM FREEZE（如 VACUUM (FREEZE, ANALYZE) 或针对最老表），必要时降低 autovacuum_vacuum_cost_delay 或提高 cost_limit 加速。根治措施：优化 autovacuum 配置（降低 freeze_max_age 提前触发、提高 worker/cost_limit）、排查长事务（长事务抬高 age）、避免频繁更新导致 XID 快速消耗、在事务中不长时间保持打开。

age 是回卷风险的量化指标。监控 age 在接近阈值前主动 VACUUM FREEZE 是根治；紧急时加速防回卷 VACUUM。长事务是 age 抬高的常见元凶。

• pg_xact 的作用
• CLOG 与可见性
• 截断与冻结协同

pg_xact（原 CLOG，commit log）记录每个事务的提交状态（in progress、committed、aborted），是 MVCC 可见性判定的核心：判断某 XID 是否已提交需查 pg_xact。pg_xact 按 XID 分页存储，会随事务增长。它的截断（truncate）把已"冻结"的旧事务对应的 commit log 段删除——因为冻结后的行不再需要查询其 XID 的提交状态（冻结即永久可见），所以这些老事务的 CLOG 记录可安全回收。截断与冻结协同：VACUUM 冻结到某 XID 后，pg_xact 可截断到该 XID 之前，避免 pg_xact 无限增长。

pg_xact 是可见性判定的"提交状态账本"，冻结让老事务不再需要 CLOG 记录，从而可截断。理解 CLOG 与冻结的协同是理解事务生命周期管理的关键。

• index-only freezing
• bottom-up deletion
• 索引膨胀控制

PostgreSQL 12+ 引入仅索引冻结（index-only freezing），在 VACUUM 处理索引时，若索引页的元组已由可见性映射（VM）标记为全可见，则无需再读取表页即可冻结索引元组，减少表页访问与冻结开销。PG 14 引入自底向上索引删除（bottom-up deletion），在清理 B-tree 索引时，从叶子层往上删除冗余的索引元组（如同一外键的多个重复项），减少索引膨胀与空间占用。两者共同减少索引膨胀与 VACUUM 冻结开销，提升 VACUUM 效率与索引空间利用率。

索引膨胀是 VACUUM 维护的难点。index-only freezing 利用 VM 减少表页读取，bottom-up deletion 清理冗余索引项，都是针对索引空间的优化。理解它们有助于调优索引膨胀。

• hint bits 与冻结标志
• VACUUM FREEZE 的机制
• 与全页写、WAL 的关系

VACUUM FREEZE 会扫描元组，把足够老（早于全局最老活跃事务）的元组的 xmin 置为 FrozenTransactionId（冻结标志），并设置 hint bits（如 xmin 已提交标志），这样后续访问无需再查 CLOG 即可判定可见。冻结操作会修改元组的头，生成 WAL 记录。全页写（full-page write）与 WAL 的关系：checkpoint 后首次被修改的页会写整页（full-page image）到 WAL，防止页面损坏时无法恢复；VACUUM FREEZE 修改页会触发全页写，从而增加 WAL 量。冻结越频繁、修改页越多，WAL 量越大。

hint bits 与冻结标志让可见性判定更快（免查 CLOG），但冻结修改页会引入全页写与 WAL 增长，是写放大的一部分。权衡冻结频率与 WAL 量是调优考量。

• 复制槽与 WAL 保留
• 监控 restart_lsn
• 清理方法

复制槽记录下游消费位置（restart_lsn），主库会保留 restart_lsn 之后的全部 WAL，防止下游丢数据。若下游（standby 或逻辑订阅端）长时间不消费或断开，主库会一直保留 WAL，导致 pg_wal 目录膨胀甚至磁盘满。监控：查询 pg_replication_slots 的 restart_lsn，用 pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) 计算落后量，落后量持续增长即堆积；结合 pg_stat_activity 的 walsender 状态。清理：修复下游消费使订阅跟上；删除不再使用的复制槽（pg_drop_replication_slot）；对物理备库其槽位可保留但在 promote 时管理。设置告警阈值监控落后量。

复制槽是"不丢 WAL"与"磁盘膨胀"的权衡。监控 restart_lsn 落后量是发现堆积的关键，清理核心是让下游消费或删槽。生产必需监控。

• XID 耗尽抢救
• 单用户模式 vacuum freeze
• pg_resetwal 风险

当数据库因 XID 耗尽（age 接近 2^31）拒绝新事务时，最大问题是无法正常启动自动 VACUUM。抢救方法：以单用户模式（single-user mode，postgres --single -D datadir）启动数据库，此时不检查 XID 限制，执行 VACUUM FREEZE 或手动 vacuum 冻结元组，把 XID 回卷风险解除后再正常启动。pg_resetwal 是重置 WAL 与 XID 的工具，风险极高：它会把 XID 计数器重置到指定值，可能造成数据损坏（如已提交事务被当作未提交、可见性错误），只在数据库已无法启动、无有效备份、需恢复启动的极端情况下使用，且可能造成数据丢失。适用边界：仅在无备份恢复且需紧急启动时，且要接受数据不一致风险。

单用户模式绕过 XID 检查执行冻结是应急首选；pg_resetwal 是"最后手段"且高危，会破坏 WAL 一致性。优先用备份恢复，其次单用户模式，pg_resetwal 慎用。

• 多进程模型的连接开销
• 内存与切换开销
• 与 MySQL 线程模型对比

PostgreSQL 采用多进程模型，每个客户端连接 fork 一个 backend 进程。创建进程（fork+初始化）开销大，且每个连接都占用独立内存（共享内存之外，每连接有 work_mem、缓存等），高并发短连接会导致大量进程创建/销毁、内存占用高、上下文切换频繁，代价高昂。MySQL 采用线程模型（每连接一线程），线程创建/切换开销小于进程，且线程间共享内存、内存占用更省，但线程需处理并发安全与锁。因此 PG 高并发短连接需前置连接池（PgBouncer），而 MySQL 原生线程相对更易处理高并发连接。

进程 vs 线程模型决定连接开销特征。PG 进程隔离性强但连接昂贵，MySQL 线程轻量但共享态复杂。理解差异是选型与架构（连接池）的根据。

• 每连接内存开销
• work_mem、temp_buffers 会话级
• 连接池的必要性

max_connections 每个连接都会占用内存：backend 进程本身（约几 MB 基础内存）、work_mem（会话级，排序/哈希等查询内存，默认 4MB，但每连接每次查询都可能分配）、temp_buffers（临时缓冲，默认 8MB）、还有 per-connection 的缓存与上下文。若把 max_connections 调到数千，虽然 work_mem 不一定同时用满，但数百连接 × 查询内存可能耗尽内存（每个连接可能分配 work_mem、temp_buffers），同时进程数增多导致上下文切换与内存压力。因此不宜简单调到数千，应前置连接池（如 PgBouncer）复用有限后端连接，控制后端连接数，降低内存与切换开销。

max_connections 上限受内存约束，work_mem/temp_buffers 是会话级（每连接），连接数 × 每连接可能内存 = 峰值内存。连接池解耦客户端连接数与后端进程数，是 PG 高并发标准架构。

• pool_size 与后端连接数
• reserve_pool 备用池
• server_lifetime 与连接复用

PgBouncer 参数影响后端连接池：pool_size 是每个数据库/用户池的最大后端连接数，决定同时有多少后端连接复用；reserve_pool 是预留的备用池，在正常池满时额外提供连接（用于高负载缓解）；server_lifetime 是后端连接在池中的最大存活时间，到期后重建（用于轮换连接、避免陈旧）；max_client_conn 是 PgBouncer 允许的最大客户端连接数（前端连接数）。pool_size 决定后端连接上限（内存与复用度），reserve_pool 增强突发处理，server_lifetime 控制连接轮换，max_client_conn 限制前端连接面。合理设置 pool_size 控制后端连接（避免超过 PG max_connections），用 reserve_pool 应对峰值。

PgBouncer 的核心是"前端连接多、后端连接少"。pool_size 控制后端连接数（关键），server_lifetime 轮换连接防止陈旧，reserve_pool 提供峰值缓冲。理解这些参数可精准配置连接池。

• auth_user 机制
• SCRAM 透传
• 安全认证

PgBouncer 的 auth_user 配置指定一个 "auth user"，当客户端连接时，PgBouncer 用该 auth user 查询后端数据库的 pg_authid（如 pg_shadow）获取客户端的密码哈希，从而完成客户端认证，无需在 PgBouncer 配置中保存明文密码。配合 SCRAM：PgBouncer 支持 SCRAM 认证透传，客户端与 PgBouncer 用 SCRAM 握手，PgBouncer 通过 auth_user 获取后端的 SCRAM 数据，再与后端完成 SCRAM 认证，全程不保存明文密码，提升安全性。auth_query 可自定义查询获取密码哈希。

auth_user 让 PgBouncer 从后端数据库动态获取密码哈希，配合 SCRAM 透传避免明文存储。这是 PgBouncer 安全认证的关键设计。

• SHOW POOLS 字段
• SHOW STATS 字段
• 连接池耗尽诊断

PgBouncer 提供管理命令诊断连接池。SHOW POOLS 显示每个池状态：cl_active（活跃客户端）、cl_waiting（等待连接的客户端数）、server_active_conn、server_idle_conn、maxwait（客户端最长等待时间）；SHOW STATS 显示累计统计：total_requests、total_received、total_sent、avg_query_count 等。连接池耗尽诊断：cl_waiting 持续大于 0 且 maxwait 增长，说明客户端等待后端连接，通常是 pool_size 不足或后端连接被占满（server_active_conn 满）；可结合后端 PG 的 max_connections 与慢查询判断。解决：调大 pool_size、清理慢查询、优化后端连接。

cl_waiting 与 maxwait 是连接池耗尽的核心指标。server_active_conn 满说明后端连接都在忙，需查慢查询或调大 pool_size。理解这些字段可快速定位连接瓶颈。

• 连接风暴的概念
• 池预热
• 指数退避与熔断

主从切换后，大量客户端同时重连新主库可能造成连接风暴（thundering herd），新主库瞬间被海量连接打满。防护措施：池预热（连接池预先建立到新主库的后端连接，避免切换瞬间全部新建）；客户端指数退避（重连失败后按指数退避随机延迟，避免同时重连）；代理层熔断（代理/负载均衡在过载时熔断或限流，保护后端）；连接池复用（客户端通过连接池重连，减少到后端的连接数）。这些措施分散重连压力，保护新主库。

连接风暴的根源是"同时重连"。池预热减少新建，指数退避分散时间，熔断保护后端。设计高可用重连策略需综合这些措施。

• 逻辑解码机制
• 各插件的用途
• 插件选择

逻辑解码（Logical Decoding）把 WAL 中的变更解码为逻辑级别的事件。插件：pgoutput 是内置默认插件，用于 publication/subscription 逻辑复制，输出二进制协议；wal2json 第三方插件，输出 JSON 格式（便于外部系统消费，如 CDC）；test_decoding 是 contrib 内置的测试插件，输出文本格式的变更说明，主要用于测试与调试逻辑解码。选型：PG 内部复制用 pgoutput，外部 CDC/JSON 消费用 wal2json，调试/教学用 test_decoding。都需 wal_level=logical 并创建逻辑复制槽。

逻辑解码插件确定解码输出格式。pgoutput 面向内部订阅，wal2json 面向外部，test_decoding 面向测试。理解差异可为 CDC 选型。

• 结构变更对逻辑解码的影响
• 兼容性问题
• 故障处理

逻辑复制槽在源表结构变更（ALTER TABLE）后可能不兼容：源表增删列、改类型后，逻辑解码输出的变更与订阅端表结构不匹配，导致应用失败。同时逻辑复制不复制 DDL，订阅端表结构不会自动更新。兼容性问题：增列后旧解码记录缺失新列、删列后多余列、类型变化导致转换失败。故障处理：源表结构变更前规划，在订阅端同步执行相同 ALTER；变更后若复制失败，需 DROP 重建或有问题的复制槽、修正订阅端结构、重置（ALTER SUBSCRIPTION ... REFRESH PUBLICATION 重新同步 schema）。PG 15+ 对部分结构变更支持更好，但整体仍需手动协调。

逻辑复制对 DDL 不敏感，结构变更需"源端+订阅端"同步。故障处理核心是"先对齐订阅端结构，再刷新/重建槽"。理解兼容性可避免复制中断。

• 应急处理
• 清理 idle 连接
• 根因治理

max_connections 打满时，新连接被拒绝。应急处理：用 pg_terminate_backend 终止异常/空闲连接（先查 pg_stat_activity 定位 idle 或长事务连接），清理 idle 连接释放连接数；必要时重启。根因治理：排查连接泄漏（应用未释放连接）、连接池未复用、慢查询占用连接、max_connections 配置过小；优化连接池（PgBouncer）、修复应用连接管理、设置 idle_in_transaction_session_timeout 自动清理空闲事务连接、调优 max_connections 与连接池配合。根本解决是控制连接数上限并复用连接，而非无脑调大 max_connections。

应急靠"终止连接释放名额"，根治靠"连接治理"（池化、超时、防泄漏）。max_connections 打满通常是连接管理问题而非配置问题。

• 代理层的作用
• 保持客户端连接
• 吸收连接风暴

云数据库连接代理（如 RDS Proxy）作为数据库与客户端之间的中间层，维护了一批后端连接池。故障转移时，代理层保持客户端连接不中断（客户端看到的连接不变），代理内部快速重连到新主库，从而缩短故障转移时间、避免客户端重连风暴。同时代理层吸收连接风暴：客户端通过代理复用连接，代理把大量客户端连接映射到少数后端连接，限制对后端的连接压力；代理可缓存连接、在故障转移时预热新主库连接。这使应用无需改动即可获得更平滑的故障转移。

代理层解耦"客户端连接"与"后端连接"。故障转移时后端重连由代理完成，客户端无感，缩短 RTO；连接池吸收风暴，保护后端。这是云数据库高可用的关键设计。