之前做运维时遇到过这么一件事：凌晨三点，数据库服务器突然宕机，业务直接停摆。值班电话一个接一个，翻箱倒柜找备用方案，结果发现根本没有——就一台单机 PostgreSQL，挂了就是挂了。

那时候最痛苦的是：每次做数据备份都要手动停库，恢复时间以小时计；监控报警了还得 SSH 登录查日志；最怕的是主库挂了之后，从库还傻乎乎等着指令。量化一下痛点：一次宕机损失至少 2 小时业务时间，数据恢复要 30 分钟到 1 小时，而且还得人工介入。

术语解释：单点故障（SPOF）
指系统中某个组件一旦失效，就会导致整个系统不可用。在数据库架构中，单机部署就是典型的单点故障风险。避免SPOF是高可用设计的核心原则之一。

后来换了 PostgreSQL 主从复制，情况变了。

主库挂了可以直接从库切换，业务中断时间从小时级缩短到分钟级；自动同步保证数据不丢失；监控一看就知道同不同步、延迟多少。最核心的改变就是：不再把鸡蛋放在一个篮子里，也不再半夜被电话叫醒修数据库。

什么是主从复制？
主从复制是一种将主数据库（Primary/Master）的数据变更实时或异步复制到一个或多个从数据库（Standby/Slave）的机制。PostgreSQL 通过 流复制（Streaming Replication） 技术实现，主库持续发送 WAL（Write-Ahead Log，预写式日志）数据，从库接收并重放这些日志，从而保持数据一致。

如果你也经历过单点故障的痛，或者正在考虑给数据库做高可用，下面这套方案可以直接用。

本文将摒弃空泛理论，以 CentOS/Ubuntu 环境下的 PostgreSQL 14 为例，手把手带你完成从零搭建、配置调优到故障演练的完整流程。无论你是 DevOps 工程师、DBA，还是希望提升系统容灾能力的开发者，都能通过本指南，真正掌握 PostgreSQL 高可用的核心实践。

让数据多一份副本，让服务少一分风险。

从今天起，告别单点故障，构建属于你的高可用数据库基石。

1. 环境准备

1.1 基础环境要求

补充说明：
- 主从服务器的时间应尽量保持同步，建议配置 NTP（网络时间协议）服务，否则可能导致复制延迟异常或 WAL 日志序号错乱。
- 网络带宽建议不低于 100 Mbps，若业务写入量较大，主从之间的网络延迟应控制在 10ms 以内，否则可能影响同步性能。

1.2 安装 PostgreSQL

还没安装 PostgreSQL 的小伙伴可以去 cpolar 官网参考《谁说没公网IP不能远程连数据库？PostgreSQL+cpolar 打通任督二脉》这篇文章哦~

安装提示：
使用官方仓库安装可以保证获取最新稳定版。CentOS 用户记得先禁用系统自带的 PostgreSQL 模块：sudo dnf module disable postgresql。Ubuntu 用户建议添加 PostgreSQL 官方 APT 源，避免版本过旧。

2. 主库配置

2.1 修改 PostgreSQL 主配置文件

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

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

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

# 1. 监听地址（允许从库连接，可指定从库IP或0.0.0.0允许所有）
listen_addresses = '*'
 
# 2. 开启归档模式（主从复制依赖）
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/14/archive/%f'  # %p=归档文件路径，%f=归档文件名
# 提前创建归档目录
mkdir -p /var/lib/pgsql/14/archive && chown -R postgres:postgres /var/lib/pgsql/14/archive
 
# 3. WAL日志配置（保证复制可靠性）
wal_level = replica  # 复制所需的WAL级别（replica/archive/logical，replica足够）
wal_buffers = 16MB   # 根据内存调整，默认通常足够
max_wal_senders = 10 # 最大并发复制连接数，大于从库数量即可
wal_keep_size = 1GB  # 保留WAL日志的大小，防止从库同步滞后导致日志被清理
 
# 4. 同步模式（可选，按需配置）
# synchronous_commit = on  # 默认同步提交，保证主从数据一致性；追求性能可设为off
# synchronous_standby_names = 'slave1'  # 指定从库名称（需与从库recovery.conf对应）
 
# 5. 其他优化（可选）
max_connections = 1000  # 大于从库的max_connections

参数详解：
- listen_addresses = '*'：允许所有网络接口上的连接，生产环境建议限制为特定从库 IP 段。
- wal_level = replica：WAL 日志级别设为 replica 才能支持复制和只读查询。
- max_wal_senders：最大并发发送 WAL 的进程数，每个从库至少占用一个。
- wal_keep_size：保留的 WAL 日志总量，防止从库落后太多导致日志被回收而无法追赶。
- hot_standby = on：允许从库在恢复期间提供只读查询，实现读写分离。
- synchronous_commit 与 synchronous_standby_names：用于配置同步复制，后文会专门说明。

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

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

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

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

host    replication     repl_user       192.168.42.145/32       md5 # 从库IP，repl_user为复制专用用户
host    all             all             192.168.42.0/24         md5 # 可选，允许内网其他机器连接

安全提示：
生产环境中不建议使用 trust 认证方式，应改为 md5 或 scram-sha-256 并设置强密码。trust 意味着无需密码即可连接，风险极高。示例中使用 trust 仅用于测试环境简化配置。

2.3 创建复制专用用户

切换到 postgres 用户，执行 SQL 命令创建用于主从复制的专用用户（需授予复制权限）：

su - postgres
psql

执行 SQL：

-- 创建复制用户（密码自定义，示例：Repl@123456）
CREATE ROLE repl_user WITH REPLICATION LOGIN ENCRYPTED PASSWORD '********';
 
-- 验证用户（可选）
\du repl_user;
 
-- 退出psql
\q

用户管理建议：
复制用户应遵循最小权限原则，只授予 REPLICATION 权限，不赋予超级用户或其他多余权限。密码需定期更换，并记录在安全的密码管理器中。

2.4 重启主库使配置生效

systemctl restart postgresql-14
systemctl status postgresql-14
sudo -u postgres psql -c "SELECT pg_is_in_recovery();" # 主库返回f（非恢复模式）

注意： 重启操作会短暂中断数据库服务，如有重要业务请提前安排维护窗口。使用 pg_ctl restart 比 systemctl restart 能更清晰地看到启动日志。

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

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

# 切换到postgres用户
su - postgres
 
# 执行备份（备份到临时目录，后续拷贝到从库）
pg_basebackup -h 192.168.42.140 -U repl_user -p 5432 -D /tmp/pg_master_backup -F p -X s -P -R
 
# 参数说明：
# -h：主库地址
# -U：复制用户
# -p：主库端口
# -D：备份目录
# -F p：输出格式为普通文件（与主库数据目录结构一致）
# -X s：备份过程中同步复制WAL日志，保证备份一致性
# -P：显示备份进度
# -R：自动生成复制所需的standby.signal文件和postgresql.auto.conf配置，简化从库配置

pg_basebackup 参数说明：
- -h：主库地址（本机可用 127.0.0.1 或 socket）
- -U：复制用户名
- -D：备份目标目录
- -Fp：输出格式为普通目录（plain），而非 tar 包
- -Xs：使用流式传输 WAL 日志，边备份边接收增量
- -P：显示进度
- -v：详细输出
- -R：自动生成从库配置文件（standby.signal 和 postgresql.auto.conf），省去手动创建步骤

备份完成后，将备份目录打包拷贝到从库的 /var/lib/pgsql/14/ 目录下（可通过 scp 传输）：

tar -zcvf pg_master_backup.tar.gz /tmp/pg_master_backup # 主库上打包备份
                                                                                                                                                                                                                                        
scp pg_master_backup.tar.gz root@192.168.1.101:/var/lib/pgsql/14  # 传输到从库

传输优化：
如果数据量很大（超过 100GB），建议使用 rsync 代替 scp，支持断点续传和增量同步。命令示例：rsync -avz --progress /tmp/pg_basebackup/ root@<从库IP>:/var/lib/pgsql/14/

到从库所在地址查看一下是否传送成功到 /var/lib/pgsql/14：

3. 从库配置

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

# 停止从库服务
systemctl stop postgresql-14
 
# 清理原有数据目录（初始化后的空目录，需替换为主库备份）
mv /var/lib/pgsql/14/data /var/lib/pgsql/14/data_bak  # 备份原有目录，防止误删
mkdir -p /var/lib/pgsql/14/data

为什么需要清理？
从库原有的数据目录必须为空或不存在，否则 pg_basebackup 恢复或解压时会报错。建议先备份原目录（如改名），而不是直接删除，以防意外。

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

# 切换到postgres用户
su - postgres
 
# 解压备份包
tar -zxvf /var/lib/pgsql/14/pg_master_backup.tar.gz -C /var/lib/pgsql/14/
 
# 移动备份数据到data目录
mv /var/lib/pgsql/14/tmp/pg_master_backup/* /var/lib/pgsql/14/data/
 
 
# 修改目录权限（必须为postgres用户和组）
chown -R postgres:postgres /var/lib/pgsql/14/data
chmod 700 /var/lib/pgsql/14/data

注意： 确保解压后的文件所有者与属组为 postgres:postgres，否则启动会因权限不足而失败。可使用 chown -R postgres:postgres /var/lib/pgsql/14/data 修正。

3.3 验证 / 修改从库复制配置

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

# 查看自动生成的复制配置
cat /var/lib/pgsql/14/data/postgresql.auto.conf

ls /var/lib/pgsql/14/data/

standby.signal 文件的作用
该文件是 PostgreSQL 12 及以上版本识别从库的标志。只要文件存在，数据库启动时就会进入 standby 恢复模式，不断从主库拉取 WAL 日志。删除此文件后重启，从库会立即提升为独立主库（常用于故障转移）。

若没有，则手动创建 standby.signal 并修改 postgresql.conf：

# 手动创建standby.signal（标识为从库）
touch /var/lib/pgsql/14/data/standby.signal
 
# 编辑postgresql.conf，添加复制配置,添加以下参数：
vim /var/lib/pgsql/14/data/postgresql.conf

# 从库专属配置
hot_standby = on  # 允许从库处于恢复模式时提供查询服务（只读）
max_connections = 500  # 小于主库的max_connections
primary_conninfo = 'user=repl_user password=Repl@123456 host=192.168.42.140 port=5432'  # 主库连接信息

3.4 启动从库服务

# 启动从库
systemctl start postgresql-14
systemctl enable postgresql-14
 
# 验证从库状态
systemctl status postgresql-14

启动后检查日志
使用 tail -f /var/lib/pgsql/14/log/postgresql-*.log 观察启动过程。正常情况会看到类似 started streaming WAL from primary 的日志。若出现错误，日志中通常有明确提示（如认证失败、网络不通、WAL 文件缺失等）。

4. 验证主从复制是否生效

4.1 主库验证复制状态

su - postgres
psql
 
# 查看复制连接状态（可看到从库的连接信息）
SELECT * FROM pg_stat_replication;
 
# 输出说明：
# - usename：repl_user（复制用户）
# - client_addr：192.168.1.101（从库IP）
# - state：streaming（表示正在流式复制）
# - sync_state：async（异步复制）或 sync（同步复制，需主库配置synchronous_commit=on）

从提供的 pg_stat_replication 查询结果来看，PostgreSQL 主从复制已经成功建立，并且处于正常运行状态。这是一个非常关键的监控视图，用于查看主库上的复制连接状态。

pg_stat_replication 关键字段解读：
- application_name：从库标识，默认是 walreceiver，可在从库配置中自定义。
- state：状态，streaming 表示正常流复制，catchup 表示追赶中。
- sync_state：同步状态，async 为异步，sync 为同步，potential 表示可能成为同步备库。
- write_lag / flush_lag / replay_lag：表示写入、刷盘、重放的延迟时间（毫秒级），是监控复制延迟的核心指标。

4.2 从库验证复制状态

su - postgres
psql
 
# 1. 验证是否处于恢复模式（从库返回t，主库返回f）
SELECT pg_is_in_recovery();

从库特有视图
pg_is_in_recovery() 函数返回 true 表示当前节点是从库且处于恢复模式。pg_last_wal_receive_lsn() 和 pg_last_wal_replay_lsn() 可查看已接收和已重放的日志位点，与主库的 pg_current_wal_lsn() 对比即可得到精确延迟。

4.3 验证主从数据一致性

# 主库创建测试表并插入数据
# 主库执行：
CREATE DATABASE test_repl;
\c test_repl;
CREATE TABLE user_info (id int, name varchar(50));
INSERT INTO user_info VALUES (1, 'test_replication');

# 从库执行（查看是否同步到数据）
\c test_repl;
SELECT * FROM user_info; 

主库：

从库：

从上图我们可以看出，主从复制成功啦！

一致性测试建议
除了简单插入测试，建议使用工具如 pgbench 生成一定量负载，再对比主从关键表的行数或校验和，更全面地验证复制正确性。

5. 主从复制常用操作

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

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

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

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

pg_ctl promote 原理
该命令会删除从库数据目录下的 standby.signal 文件，并停止恢复模式，将数据库变为可读写的主库。提升后原主库恢复时不会自动成为从库，需要手动重新搭建或使用 pg_rewind 工具回滚。

生产环境故障转移注意事项：
- 提升前应确认原主库确实不可恢复，避免“脑裂”（两个主库同时写入）。
- 建议配合 VIP（虚拟IP）或负载均衡器实现自动切换，而非人工登录执行。
- 更成熟的方案可选用 Patroni、repmgr 等自动化高可用框架。

5.2 监控复制延迟

# 从库执行，查看复制延迟（单位：秒）
SELECT 
  now() - pg_last_xact_replay_timestamp() AS replication_delay;

延迟告警阈值建议
- 正常延迟 < 1 秒，可忽略。
- 延迟 10~30 秒：警告，需检查网络或主库写入负载。
- 延迟超过 1 分钟：严重，可能导致 WAL 日志被主库回收，从库永久落后需重建。
- 建议配置 Prometheus + pg_exporter 或 Zabbix 采集这些指标，并设置告警规则。

5.3 新增从库

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

级联复制场景
当有多个从库且主库压力较大时，可以让部分从库从另一个从库同步数据，减少主库的 wal_sender 连接数。配置方法：在中间从库的 postgresql.conf 中设置 wal_level = replica 并开启 max_wal_senders，然后让末端从库的 primary_conninfo 指向中间从库。

5.4 拓展：同步复制 vs 异步复制

专家建议： 生产环境建议配置至少一个同步从库和一个异步从库。同步保证核心数据不丢，异步用于备份和只读查询。同时设置 synchronous_standby_names = 'FIRST 1 (sync_standby)' 实现灵活策略。

6. 实现随时随地开发

回想一下，在开发、测试，甚至小型项目交付中，你是否也曾陷入这样的困境：

• “我在家搭了个 PostgreSQL 数据库，同事怎么连不上？”
• “客户急着看 Demo，可服务跑在内网，根本没法访问！”
• “没有公网 IP，难道只能租云服务器，或者干脆放弃远程演示？”

别焦虑——没有公网 IP，并不意味着你的服务只能困在局域网里。 借助一个轻量级但强大的内网穿透工具，你可以轻松将本地运行的 PostgreSQL 服务“暴露”到公网，自动生成一个安全、可分享的 HTTPS 隧道地址。无论你身处家庭宽带、公司防火墙后，还是校园网深处，外部用户都能像访问普通网站一样，通过标准端口安全连接你的数据库。本文将手把手带你完成这一过程：从零配置，到安全地将 PostgreSQL 服务映射至公网，打通内网与外部世界的连接通道。从此，“我的数据库在哪，服务就在哪” 不再是一句空话。准备好了吗？让我们开启这场高效、安全、低成本的“内网突围”之旅！

6.1 它是什么？

它是一款安全高效的内网穿透工具，无需公网 IP 或复杂配置，只需一条命令，即可将本地服务器、Web 服务或任意端口映射到公网，让你随时随地远程访问内网应用，特别适合开发调试、远程运维和应急部署等场景。

内网穿透原理简述
工具客户端（如 cpolar）与云端服务器建立长连接，用户在公网访问云端分配的域名+端口时，云端将请求通过隧道转发到本地客户端，再由客户端转发到本地指定服务。整个过程对终端用户透明。

6.2 部署

它可以将你本地电脑中的服务（如 SSH、Web、数据库）映射到公网。即使你在家里或外出时，也可以通过公网地址连接回本地运行的开发环境。

❤️以下是安装步骤：

使用一键脚本安装命令：

sudo curl https://get.cpolar.sh | sh

安装完成后，执行下方命令查看

sudo systemctl status cpolar

安装和成功启动服务后，在浏览器上输入虚拟机主机 IP 加 9200 端口即：http://localhost:9200 访问管理界面，使用官网注册的账号登录，登录后即可看到 web 配置界面，接下来在 web 界面配置即可：

打开浏览器访问本地 9200 端口，使用账户密码登录即可，登录后即可对隧道进行管理。

安全提醒：
内网穿透工具虽然方便，但也将内部服务暴露到了公网。务必为 PostgreSQL 配置强密码、启用 SSL，并定期检查访问日志。对于生产敏感数据，不建议长期使用临时隧道，而应使用固定隧道并配合 IP 白名单。

7. 配置公网地址

通过配置，你可以在本地 WSL 或 Linux 系统上运行 SSH 服务，并通过它将其映射到公网，从而实现从任意设备远程连接开发环境的目的。

• 隧道名称：可自定义，本例使用了：postgres，注意不要与已有的隧道名称重复
• 协议：tcp
• 本地地址：192.168.42.140:5432
• 端口类型：随机临时 TCP 端口
• 地区：China Vip

创建成功后，打开左侧在线隧道列表，可以看到刚刚通过创建隧道生成了公网地址，接下来就可以在其他电脑或者移动端设备（异地）上，使用任意一个地址在终端中访问即可。

• tcp 表示使用的协议类型
• tcp.vip.cpolar.cn 是 Cpolar 提供的域名
• 11084 是随机分配的公网端口号

通过它提供的公网地址和端口，使用 SSH 协议从任意一台主机连接到 postgres 账号啦！

psql -h 2.tcp.vip.cpolar.cn -p 11084 -U postgres -d mydb

临时隧道 vs 固定隧道
临时隧道（随机端口）适合短期调试，每次重启或重新创建会变化，不适合长期服务。固定隧道需要付费或 VIP 套餐，端口保持不变，适合对外提供稳定访问。

8. 保留固定 TCP 公网地址

使用为其配置 TCP 地址，该地址为固定地址，不会随机变化。

选择区域和描述：有一个下拉菜单，当前选择的是“China VIP”。
右侧输入框，用于填写描述信息。
保留按钮：在右侧有一个橙色的“保留”按钮，点击该按钮可以保留所选的 TCP 地址。
列表中显示了一条已保留的 TCP 地址记录。

• 地区：显示为“China VIP”。
• 地址：显示为“8.tcp.vip.cpolar.cn:13299”。

登录 web UI 管理界面，点击左侧仪表盘的隧道管理——隧道列表，找到所要配置的隧道 postgres，点击右侧的 编辑。

修改隧道信息，将保留成功的 TCP 端口配置到隧道中。

• 端口类型：选择固定 TCP 端口
• 预留的 TCP 地址：填写保留成功的 TCP 地址

点击 更新。

创建完成后，打开在线隧道列表，此时可以看到随机的公网地址已经发生变化，地址名称也变成了保留和固定的 TCP 地址。

最后测试一下固定的地址是否好用，测试命令：

psql -h 8.tcp.vip.cpolar.cn -p 13299 -U postgres -d mydb

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

9. 未来趋势：从主从复制到云原生高可用

随着容器化和 Kubernetes 的普及，传统的主从复制正在被 Operator 模式（如 Crunchy Data PGO、Zalando Patroni）替代。这些方案能自动处理故障转移、备份、扩缩容，并将数据库状态声明为代码。但对于中小团队或传统运维环境，手工搭建主从复制仍是理解高可用原理的必经之路。

学习路径建议
1. 掌握单机 PostgreSQL 基本管理 →
2. 搭建异步主从复制 →
3. 引入同步复制和监控 →
4. 使用 Patroni + etcd 实现自动化切换 →
5. 迁移至 Kubernetes 上的 CloudNative PG。

总结

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

不用主从复制时：

• 数据库宕机 = 业务停摆，恢复靠手动
• 备份要停机，数据有丢失风险
• 维护升级必须 downtime
• 全靠人工救火

用了主从复制后：

• 主库挂了可以快速切换到从库
• 数据实时同步，最多丢失几秒（异步模式下）
• 从库可以分担读取压力
• 运维从救火变成预防

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

常见配置错误与注意事项：
- ❌ 主库 wal_level 未设为 replica 或 logical
- ❌ pg_hba.conf 未正确添加从库 IP 的复制权限
- ❌ 从库数据目录权限不是 postgres 用户
- ❌ 防火墙未开放 PostgreSQL 端口（5432）或 SSH 端口
- ❌ 主从服务器时间不同步导致 WAL 位点混乱
- ✅ 建议在正式上线前进行故障演练：手动停止主库、提升从库、再将原主库重新加入复制集群。

如果你也有类似的痛点，比如担心单点故障、想降低运维压力，可以试试这个方案。先在测试环境跑通再上生产，别直接怼线上。