Postgresql中PG_REWIND有什么用

发布时间：2021-11-26 09:19:34 作者：小新
来源：亿速云阅读：181

# PostgreSQL中PG_REWIND有什么用

## 引言

在PostgreSQL的高可用架构中，主从切换是常见的运维操作。当主库发生故障时，通常会提升一个从库作为新的主库。然而，原主库恢复后可能包含与新主库冲突的数据变更，直接重新加入集群会导致数据不一致。`pg_rewind`正是为解决这一问题而设计的利器。

本文将深入探讨`pg_rewind`的工作原理、适用场景、使用方法和注意事项，帮助DBA高效处理PostgreSQL集群的脑裂修复问题。

---

## 一、PG_REWIND概述

### 1.1 基本定义
`pg_rewind`是PostgreSQL自带的一个命令行工具（9.5版本引入），用于将一个脱离集群的主库与当前主库同步，通过"回退"不需要的变更使其能够作为从库重新加入集群。

### 1.2 核心价值
传统修复方法需要全量重建从库，而`pg_rewind`可以：
- **节省时间**：只同步差异部分，避免完整基础备份
- **节省空间**：无需额外的存储空间存放备份
- **减少停机**：缩短故障恢复时间窗口

### 1.3 工作原理
通过对比两个数据库集群的WAL（Write-Ahead Logging）历史，识别分叉点后的差异：
1. 扫描原主库和新主库的WAL记录
2. 定位时间线分叉点（timeline split point）
3. 将原主库回退到分叉点状态
4. 从新主库复制分叉点后的变更

---

## 二、适用场景分析

### 2.1 典型使用场景
1. **主库故障转移后**：原主库恢复时需要重新加入集群
2. **计划内切换**：手动主从切换后的原主库重配置
3. **误操作恢复**：当从库意外写入数据后需要重新同步

### 2.2 不适用情况
- 非时间线分叉导致的不一致（如文件系统级损坏）
- PostgreSQL大版本升级后的同步
- 开启了`wal_level=minimal`的实例

### 2.3 版本兼容性
| PostgreSQL版本 | 功能支持 |
|----------------|----------|
| < 9.5          | 不可用   |
| 9.5-10         | 基础功能 |
| 11+            | 增强性能 |

---

## 三、工作原理深度解析

### 3.1 关键概念：时间线（Timeline）
PostgreSQL使用时间线ID区分不同的WAL历史分支。每次提升新主库时会递增时间线号。

### 3.2 核心处理流程
1. **分叉点检测**
   - 解析新旧主库的`pg_wal`目录
   - 查找最后一个共同的WAL位置（LSN）

2. **文件系统扫描**
   - 使用`filemap`机制对比数据文件差异
   - 三类文件处理：
     - 保持不变（未修改文件）
     - 需要替换（冲突文件）
     - 需要复制（新增文件）

3. **WAL重放**
   - 从新主库获取缺失的WAL段
   - 应用这些WAL使数据库达到一致状态

### 3.3 技术限制
- 要求旧主库的WAL至少保留到分叉点
- 需要`full_page_writes=on`（默认值）
- 不能处理非WAL管理的文件（如临时文件）

---

## 四、实战操作指南

### 4.1 前置条件检查
```bash
# 确保参数配置正确
psql -c "SHOW wal_level;"       # 必须为replica或logical
psql -c "SHOW full_page_writes;" # 建议为on

4.2 基本使用语法

pg_rewind \
  --target-pgdata=/var/lib/pgsql/old_primary \
  --source-server="host=new_primary user=postgres port=5432" \
  --progress

4.3 分步操作示例

场景：原主库在10:00故障，从库在10:05被提升为新主库

停止原主库服务

pg_ctl stop -D /var/lib/pgsql/old_primary

执行rewind操作

pg_rewind \
 --target-pgdata=/var/lib/pgsql/old_primary \
 --source-server="host=new_primary user=rep_user" \
 --dry-run  # 先进行试运行

配置为从库启动

echo "primary_conninfo = 'host=new_primary'" > /var/lib/pgsql/old_primary/recovery.conf
pg_ctl start -D /var/lib/pgsql/old_primary

4.4 常见问题处理

问题1：WAL日志不完整

error: could not find common ancestor

解决方案：确保旧主库保留足够的WAL日志，或手动从归档恢复

问题2：连接认证失败调整pg_hba.conf允许复制用户连接

五、性能优化建议

5.1 参数调优

# postgresql.conf优化
wal_keep_segments = 1024      # 保留更多WAL段
max_wal_senders = 10          # 增加WAL发送进程

5.2 操作优化

在低峰期执行rewind操作
使用--no-ensure-shutdown加速（需确保数据库已干净关闭）
并行复制（PostgreSQL 13+支持--jobs参数）

5.3 监控指标

-- 检查同步进度
SELECT * FROM pg_stat_replication;

六、替代方案对比

方案	优点	缺点
pg_rewind	快速，增量同步	有前置条件限制
全量基础备份	绝对干净	耗时且占用资源
逻辑复制	可选择性同步	需要预先配置

七、最佳实践总结

预防优于修复：合理配置wal_keep_segments和归档
自动化集成：将pg_rewind纳入故障恢复流程
定期演练：在测试环境验证rewind操作
监控完备：部署WAL空间监控和复制延迟告警

结语

pg_rewind作为PostgreSQL高可用架构中的关键工具，能显著降低主从切换后的恢复成本。理解其工作原理和适用边界，结合合理的运维流程，可以极大提升数据库系统的可用性。随着PostgreSQL的持续演进，该工具的功能和性能仍在不断优化，值得DBA们深入掌握。

注意：本文基于PostgreSQL 15编写，部分参数在不同版本中可能存在差异。 “`

这篇文章共计约2600字，采用Markdown格式编写，包含： 1. 多级标题结构 2. 技术原理图解说明 3. 代码块示例 4. 表格对比 5. 实操命令 6. 常见问题解决方案 7. 版本兼容性说明

可根据需要调整具体内容细节或补充特定版本的注意事项。