
## 引言：从凌晨三点的宕机警报说起

曾经在运维岗位上经历过这样的场景：凌晨三点，数据库服务器突然宕机，业务系统全面停摆。值班电话一个接一个响起，翻箱倒柜寻找备用方案，结果发现根本没有——就一台单机PostgreSQL，挂了就是挂了。

那时候最痛苦的是：
- **每次数据备份都要手动停库**，恢复时间以小时计
- **监控报警后还需SSH登录查日志**，响应速度慢
- **主库挂了之后，备库还傻乎乎等着指令**，无法自动接管

量化一下痛点：一次宕机损失至少2小时业务时间，数据恢复要30分钟到1小时，而且还得人工介入。

后来引入了PostgreSQL主从复制，情况彻底改变：
- **主库挂了可以直接备库切换**，业务中断时间从小时级缩短到分钟级
- **自动同步保证数据不丢失**，最多丢失几秒的数据
- **监控一目了然**，同不同步、延迟多少都能实时掌握

最核心的改变就是：不再把鸡蛋放在一个篮子里，也不再半夜被电话叫醒修数据库。

如果你也经历过单点故障的痛，或者正在考虑给数据库做高可用，下面这套方案可以直接用。本文将摒弃空泛理论，以CentOS/Ubuntu环境下的PostgreSQL 14为例，手把手带你完成从零搭建、配置调优到故障演练的完整流程。

**让数据多一份副本，让服务少一分风险。从今天起，告别单点故障，构建属于你的高可用数据库基石。**

## 第一部分：环境准备与基础架构

### 1.1 基础环境要求

在开始配置之前，确保你的环境满足以下要求：

| 节点类型 | 服务器地址 | 系统版本 | PostgreSQL版本 | 核心要求 |
|---------|-----------|----------|---------------|----------|
| 主库（Primary） | 192.168.50.120（示例） | CentOS 7/8/9或Ubuntu 20.04+ | 14 | 开启网络端口、关闭防火墙/放行5432端口 |
| 备库（Replica） | 192.168.50.125（示例） | 与主库一致 | 与主库完全一致 | 与主库网络互通、磁盘空间不小于主库 |

**重要提醒**：主备库的PostgreSQL版本必须完全一致，否则可能导致兼容性问题。

### 1.2 安装PostgreSQL

如果尚未安装PostgreSQL，建议参考官方文档或使用包管理器进行安装：

**CentOS/RHEL**：
```bash
# 添加官方仓库
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# 安装PostgreSQL 14
sudo dnf install -y postgresql14-server postgresql14-contrib

# 初始化数据库
sudo /usr/pgsql-14/bin/postgresql-14-setup initdb

# 启动服务
sudo systemctl enable --now postgresql-14
```

**Ubuntu/Debian**：
```bash
# 导入GPG密钥
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

# 添加APT仓库
echo "deb http://apt.postgresql.org/pub/apt/ $(lsb_release -cs)-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list

# 更新并安装
sudo apt update
sudo apt install -y postgresql-14 postgresql-client-14

# 服务已自动启动
```

## 第二部分：主库配置详解

### 2.1 修改PostgreSQL主配置文件

主配置文件路径：`/var/lib/pgsql/14/data/postgresql.conf`

```bash
vim /var/lib/pgsql/14/data/postgresql.conf
```

修改以下核心参数（取消注释并调整值）：

```conf
# 1. 监听地址（允许备库连接，可指定备库IP或0.0.0.0允许所有）
listen_addresses = '*'

# 2. 开启归档模式（主从复制依赖）
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/14/wal_archive/%f'
# 提前创建归档目录
# mkdir -p /var/lib/pgsql/14/wal_archive && chown -R postgres:postgres /var/lib/pgsql/14/wal_archive

# 3. WAL日志配置（保证复制可靠性）
wal_level = replica   # 复制所需的WAL级别（replica/archive/logical，replica足够）
wal_buffers = 16MB    # 根据内存调整，默认通常足够
max_wal_senders = 8   # 最大并发复制连接数，大于备库数量即可
wal_keep_size = 2GB   # 保留WAL日志的大小，防止备库同步滞后导致日志被清理

# 4. 同步模式（可选，按需配置）
# synchronous_commit = on  # 默认同步提交，保证主备数据一致性；追求性能可设为off
# synchronous_standby_names = 'replica1'  # 指定备库名称（需与备库recovery.conf对应）

# 5. 其他优化（可选）
max_connections = 800 # 大于备库的max_connections
```

### 2.2 修改客户端认证配置文件

文件路径：`/var/lib/pgsql/14/data/pg_hba.conf`

```bash
vim /var/lib/pgsql/14/data/pg_hba.conf
```

添加备库的连接授权（允许备库IP通过复制用户连接）：

```conf
# 允许备库IP通过复制用户连接
host    replication     pg_replicator       192.168.50.125/32       md5

# 可选：允许内网其他机器连接
host    all             all             192.168.50.0/24         md5
```

### 2.3 创建复制专用用户

切换到postgres用户，执行SQL命令创建用于主从复制的专用用户：

```bash
su - postgres
psql
```

执行SQL：
```sql
-- 创建复制用户（密码自定义，示例：Replica@2026!）
CREATE ROLE pg_replicator WITH REPLICATION LOGIN ENCRYPTED PASSWORD 'Replica@2026!';

-- 验证用户（可选）
\du pg_replicator;

-- 退出psql
\q
```

### 2.4 重启主库使配置生效

```bash
systemctl restart postgresql-14
systemctl status postgresql-14

# 验证主库状态（返回f表示非恢复模式）
sudo -u postgres psql -c "SELECT pg_is_in_recovery();"
```

### 2.5 备份主库数据（供备库初始化）

使用`pg_basebackup`工具备份主库数据，该工具专门用于PostgreSQL复制环境的备库初始化：

```bash
# 切换到postgres用户
su - postgres

# 执行备份（备份到临时目录，后续拷贝到备库）
pg_basebackup -h 192.168.50.120 -U pg_replicator -p 5432 -D /tmp/pg_primary_backup -F p -X s -P -R
```

**参数说明**：
- `-h`：主库地址
- `-U`：复制用户
- `-p`：主库端口
- `-D`：备份目录
- `-F p`：输出格式为普通文件（与主库数据目录结构一致）
- `-X s`：备份过程中同步复制WAL日志，保证备份一致性
- `-P`：显示备份进度
- `-R`：自动生成复制所需的standby.signal文件和postgresql.auto.conf配置，简化备库配置

备份完成后，将备份目录打包拷贝到备库：

```bash
# 主库上打包备份
tar -zcvf pg_primary_backup.tar.gz /tmp/pg_primary_backup

# 传输到备库
scp pg_primary_backup.tar.gz root@192.168.50.125:/var/lib/pgsql/14/
```

## 第三部分：备库配置详解

### 3.1 停止备库PostgreSQL服务并清理原有数据目录

```bash
# 停止备库服务
systemctl stop postgresql-14

# 清理原有数据目录（初始化后的空目录，需替换为主库备份）
mv /var/lib/pgsql/14/data /var/lib/pgsql/14/data_original  # 备份原有目录
mkdir -p /var/lib/pgsql/14/data
```

### 3.2 解压主库备份到备库数据目录

```bash
# 切换到postgres用户
su - postgres

# 解压备份包
tar -zxvf /var/lib/pgsql/14/pg_primary_backup.tar.gz -C /var/lib/pgsql/14/

# 移动备份数据到data目录
mv /var/lib/pgsql/14/tmp/pg_primary_backup/* /var/lib/pgsql/14/data/

# 修改目录权限（必须为postgres用户和组）
chown -R postgres:postgres /var/lib/pgsql/14/data
chmod 700 /var/lib/pgsql/14/data
```

### 3.3 验证/修改备库复制配置

由于主库备份时使用了`-R`参数，会自动生成`standby.signal`（标识备库身份）和`postgresql.auto.conf`（包含复制连接信息），无需手动创建。

**验证自动生成的配置**：
```bash
# 查看自动生成的复制配置
cat /var/lib/pgsql/14/data/postgresql.auto.conf

# 确认standby.signal存在
ls /var/lib/pgsql/14/data/standby.signal
```

**如果没有自动生成，则手动配置**：

```bash
# 手动创建standby.signal（标识为备库）
touch /var/lib/pgsql/14/data/standby.signal

# 编辑postgresql.conf，添加复制配置
vim /var/lib/pgsql/14/data/postgresql.conf
```

添加以下参数：
```conf
# 备库专属配置
hot_standby = on   # 允许备库处于恢复模式时提供查询服务（只读）
max_connections = 400 # 小于主库的max_connections
primary_conninfo = 'user=pg_replicator password=Replica@2026! host=192.168.50.120 port=5432' # 主库连接信息
```

### 3.4 启动备库服务

```bash
# 启动备库
systemctl start postgresql-14
systemctl enable postgresql-14

# 验证备库状态
systemctl status postgresql-14
```

## 第四部分：验证主从复制状态

### 4.1 主库验证复制状态

```bash
su - postgres
psql

# 查看复制连接状态（可看到备库的连接信息）
SELECT * FROM pg_stat_replication;
```

**输出说明**：
- `usename`：pg_replicator（复制用户）
- `client_addr`：192.168.50.125（备库IP）
- `state`：streaming（表示正在流式复制）
- `sync_state`：async（异步复制）或sync（同步复制，需主库配置synchronous_commit=on）

### 4.2 备库验证复制状态

```bash
su - postgres
psql

# 验证是否处于恢复模式（备库返回t，主库返回f）
SELECT pg_is_in_recovery();
```

### 4.3 验证主备数据一致性

**主库创建测试表并插入数据**：
```sql
-- 主库执行：
CREATE DATABASE demo_replication;
\c demo_replication;
CREATE TABLE customer_data (id int, email varchar(100));
INSERT INTO customer_data VALUES (1001, 'demo@replication.test');
```

**备库验证数据同步**：
```sql
-- 备库执行：
\c demo_replication;
SELECT * FROM customer_data;
```

如果备库能够查询到主库插入的数据，说明主从复制成功！

## 第五部分：主从复制高级操作

### 5.1 切换主备（故障转移，简易版）

当主库故障时，可将备库提升为主库：

```bash
# 备库执行（停止恢复模式，提升为主库）
su - postgres
psql -c "SELECT pg_promote();"

# 验证：提升后备库pg_is_in_recovery()返回f
psql -c "SELECT pg_is_in_recovery();"
```

**注意**：此方法为简易故障转移，生产环境中建议使用Patroni等专业工具实现自动故障转移。

### 5.2 监控复制延迟

```bash
# 备库执行，查看复制延迟（单位：秒）
su - postgres
psql -c "SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;"
```

**延迟监控最佳实践**：
- 设置监控告警，当延迟超过阈值时及时通知
- 定期检查网络带宽和磁盘I/O性能
- 考虑使用同步复制模式减少数据丢失风险

### 5.3 新增备库

只需重复"备库配置"步骤，使用主库（或现有备库，需开启级联复制）的pg_basebackup备份初始化即可。

**级联复制配置**（备库作为其他备库的主库）：
```conf
# 在备库的postgresql.conf中添加
max_wal_senders = 15  # 增加WAL发送进程数
wal_level = replica
```

### 5.4 性能优化建议

**主库优化**：
- 根据负载调整`wal_buffers`和`shared_buffers`
- 合理设置`max_wal_senders`，避免资源浪费
- 使用SSD存储提高WAL写入性能

**备库优化**：
- 启用`hot_standby_feedback`减少主库的vacuum压力
- 调整`max_standby_streaming_delay`控制查询取消行为
- 备库可以承担读取负载，实现读写分离

## 第六部分：公网访问与远程管理

### 6.1 内网穿透解决方案

在开发、测试或小型项目交付中，经常遇到这样的困境：
- "我在家搭了个PostgreSQL数据库，同事怎么连不上？"
- "客户急着看Demo，可服务跑在内网，根本没法访问！"
- "没有公网IP，难道只能租云服务器，或者干脆放弃远程演示？"

**解决方案**：使用内网穿透工具（如frp或ngrok）将本地PostgreSQL服务映射到公网。

### 6.2 frp部署与配置

**安装frp服务端和客户端**：
```bash
# 下载frp（以Linux AMD64为例）
wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz
tar -zxvf frp_0.54.0_linux_amd64.tar.gz
cd frp_0.54.0_linux_amd64
```

**配置frpc客户端**（在数据库服务器上）：
```ini
# frpc.ini
[common]
server_addr = your-frp-server.com
server_port = 7000
token = your-frp-token

[postgres-tunnel]
type = tcp
local_ip = 192.168.50.120
local_port = 5432
remote_port = 6000
```

**启动frpc**：
```bash
./frpc -c frpc.ini
```

**使用公网地址连接**：
```bash
# 使用分配的公网地址和端口
psql -h your-frp-server.com -p 6000 -U postgres -d myapp
```

这样，我们成功打破了"没有公网IP就无法远程访问数据库"的固有认知。

## 第七部分：生产环境最佳实践

### 7.1 安全加固措施

**网络安全**：
- 使用防火墙限制只允许特定IP访问5432端口
- 启用SSL/TLS加密复制流量
- 定期更新PostgreSQL版本修复安全漏洞

**权限管理**：
- 复制用户仅授予REPLICATION权限
- 应用用户使用最小权限原则
- 定期审计用户权限和访问日志

### 7.2 监控与告警

**关键监控指标**：
- 复制延迟时间
- WAL生成速率
- 备库连接状态
- 磁盘空间使用率

**告警策略**：
- 复制延迟超过30秒告警
- 备库断开连接立即告警
- 磁盘空间使用率超过80%告警

### 7.3 备份策略

**多层次备份**：
- **实时复制**：主从复制提供实时数据保护
- **定期快照**：每日全量备份 + WAL归档
- **异地备份**：将备份文件同步到异地存储

**恢复测试**：
- 定期进行恢复演练
- 验证备份文件的完整性
- 测试故障转移流程

## 总结：主从复制的价值与局限

对比下来，单库和主从复制的差别很明显：

**不用主从复制时**：
- 数据库宕机 = 业务停摆，恢复靠手动
- 备份要停机，数据有丢失风险
- 维护升级必须downtime
- 全靠人工救火

**用了主从复制后**：
- 主库挂了可以快速切换到备库
- 数据实时同步，最多丢失几秒
- 备库可以分担读取压力
- 运维从救火变成预防

**但也要承认，主从复制不是万能药**：
- 配置错了照样出问题
- 网络不稳定会有延迟
- 高并发场景还要考虑读写分离
- 异步复制模式下主库挂了还是可能有数据丢失
- 真正要求不丢数据得上同步复制或者PgBouncer等更复杂的方案

**实施建议**：
1. **先在测试环境跑通**再上生产，别直接怼线上
2. **制定详细的故障转移预案**，包括手动和自动两种方式
3. **建立完善的监控体系**，及时发现和解决问题
4. **定期进行灾难恢复演练**，确保方案的有效性

如果你也有类似的痛点，比如担心单点故障、想降低运维压力，可以试试这个方案。PostgreSQL主从复制是构建高可用数据库的基础，也是每个DBA和DevOps工程师必备的核心技能。

**记住：高可用不是一蹴而就的，而是通过持续的优化和完善逐步实现的。从今天开始，让你的数据库告别单点故障！**

曾经在运维岗位上经历过这样的场景：凌晨三点，数据库服务器突然宕机，业务系统全面停摆。值班电话一个接一个响起，翻箱倒柜寻找备用方案，结果发现根本没有——就一台单机PostgreSQL，挂了就是挂了。

PostgreSQL主从复制实战：告别单点故障，构建高可用数据库基石

如果你也经历过单点故障的痛，或者正在考虑给数据库做高可用，下面这套方案可以直接用。本文将摒弃空泛理论，以CentOS/Ubuntu环境下的PostgreSQL 14为例，手把手带你完成从零搭建、配置调优到故障演练的完整流程。

数据库

运维

后端

PostgreSQL主从复制配置教程：手把手教你搭建高可用数据库集群，解决单点故障问题。从环境准备、主备库配置到故障转移演练，详细讲解CentOS/Ubuntu下PostgreSQL14主从复制方案，实现分钟级故障恢复和数据零丢失，告别凌晨宕机警报。

数据一致性

数据恢复

数据同步

数据保护

数据监控

数据备份

网络安全

云服务器

数据丢失

PostgreSQL

防火墙

服务器

DevOps

CentOS

Ubuntu

2026采购季 | AI焕新·智启新局

tbase

postgres

tencentdb-catalog

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PostgreSQL主从复制实战：告别单点故障，构建高可用数据库基石-腾讯云开发者社区-腾讯云

PostgreSQL主从复制实战：告别单点故障，构建高可用数据库基石

PostgreSQL主从复制实战：告别单点故障，构建高可用数据库基石

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐