企业官网建设流程全解析

PG 13 pg_basebackup 重建从库 — 操作与排坑文档

环境

零、重建前检查（必做！别跳过）

动手之前在主库上跑一遍，确认三件事：从库真坏了、归档开着、WAL 够用。

0.1 从库 —— 确认真的需要重建

-- 从库上查（连得上查 SQL，连不上看日志）SELECTstatus,sender_host,pg_size_pretty(pg_wal_lsn_diff(pg_last_wal_receive_lsn(),pg_last_wal_replay_lsn()))ASlagFROMpg_stat_wal_receiver;

• streaming+ lag ≈ 0 → 正常，不需要重建
• streaming+ lag 持续涨 → 先查磁盘/网络，追不上再重建
• 连不上 / 进程在但 SQL 不通 → 大概率要重建，看日志确认

# 从库连不上时，直接看 PG 日志搜错误grep-E"incorrect prevlink|corrupt|FATAL|PANIC"/var/lib/pgsql/13/data/log/postgresql-*.log|tail-20

看到record with incorrect prev-link→ WAL 物理损坏，必须重建。其余情况（could not receive data、could not connect等）先排查网络和主库状态。

0.2 主库 —— 确认归档 & WAL 保留

-- 在主库一条 SQL 查完关键配置SELECTname,settingFROMpg_settingsWHEREnameIN('archive_mode','archive_command','wal_keep_size','wal_level');

-- 再看 replication slot（有则额外保险）SELECTslot_name,active,pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn))ASretainedFROMpg_replication_slots;-- active = t → 有 slot 兜底，WAL 不会被清

结论：archive_mode = off+wal_keep_size很小 + 没有 active slot → 危险。要么开归档，要么重建前临时调大wal_keep_size：

ALTERSYSTEMSETwal_keep_size='10GB';SELECTpg_reload_conf();

一般 10GB 足够了。除非数据目录几百 GB 以上、备份要跑半小时以上，再酌情加大。

0.3 从库到主库连通性

# 在从库上测，免得 firewall / pg_hba.conf 没配PGPASSWORD='<REPL_PASSWORD>'/usr/pgsql-13/bin/psql-h<MASTER_IP>-Ureplicator-dpostgres-c"SELECT 1"

通了再往下走；不通先查主库pg_hba.conf（见下一节）。

0.4 记基线

-- 主库执行，备份跑完回来对比SELECTpg_current_wal_lsn()ASbefore_backup_lsn;

一、主库配置（一次性）

主库pg_hba.conf添加复制用户：

host replication replicator <STANDBY_IP>/32 md5

创建复制用户：

CREATEROLE replicatorWITHREPLICATIONLOGIN PASSWORD'<REPL_PASSWORD>';SELECTpg_reload_conf();

二、pg_basebackup 重建从库

2.1 停从库 + 清空数据目录

sudo-upostgres /usr/pgsql-13/bin/pg_ctl stop-mfast-D/var/lib/pgsql/13/data/rm-rf/var/lib/pgsql/13/data/*

2.2 执行 pg_basebackup

sudo-upostgresenvPGPASSWORD='<REPL_PASSWORD>'nohup/usr/pgsql-13/bin/pg_basebackup\-h<MASTER_IP>-p5432-Ureplicator\-D/var/lib/pgsql/13/data-P-R-Xstream\>/tmp/pg_basebackup.log2>&1&echo"PID:$!"

2.3 看进度

# 实时看tail-f/tmp/pg_basebackup.log# 跑完后看最终结果tail-5/tmp/pg_basebackup.log# 看到 "kB (100%), 1/1 tablespace" = 完成# 数据目录大小在涨就是在传du-sh/var/lib/pgsql/13/data/

2.4 起库

sudo-upostgres /usr/pgsql-13/bin/pg_ctl start-D/var/lib/pgsql/13/data/

2.5 验证

-- 1. 从库 walreceiver 状态SELECT*FROMpg_stat_wal_receiver;-- status = streamingSELECTnow()-pg_last_xact_replay_timestamp();-- 延迟应接近 0-- 2. 看从库追到哪了SELECTpg_last_wal_replay_lsn()ASstandby_replay_lsn;-- 3. 切到主库，看主库当前写到哪了-- (从库上跑也行，连主库查)-- 对比 0.4 记录的 before_backup_lsn：-- - 从库 replay_lsn > before_backup_lsn → 重建成功，且已经追过备份起点 ✅-- - 从库 replay_lsn == before_backup_lsn → 重建完成了但在备份点没动 ⚠️ 等一会再查-- - 从库 replay_lsn < before_backup_lsn → 不正常，检查日志

三、常见问题

坑 1：command not found

sudo -u postgres不加载/usr/pgsql-13/bin/。用完整路径/usr/pgsql-13/bin/pg_basebackup。

坑 2：could not change directory to "/root"

sudo -u postgres在/root下执行时 postgres 用户无权访问，打印这行警告。不影响备份，或者在/tmp下跑就不会出现。

坑 3：密码不传卡死

.pgpass位置或权限不对时会卡住等密码。用env PGPASSWORD='...'直接传，零依赖。

坑 4：进程残留

多次失败后ps aux | grep pg_basebackup看到一堆僵尸进程：

pkill-9-fpg_basebackup

四、完整执行脚本（可复用）

#!/bin/bash# pg_basebackup 从库重建（后台执行 + du 监控）MASTER_HOST='<MASTER_IP>'MASTER_USER=replicatorMASTER_PASS='<REPL_PASSWORD>'PG_DATA=/var/lib/pgsql/13/dataPG_BIN=/usr/pgsql-13/bin# 1. 停从库sudo-upostgres${PG_BIN}/pg_ctl stop-mfast-D${PG_DATA}2>/dev/null# 2. 清空rm-rf${PG_DATA}/*# 3. 后台拉cd/tmpsudo-upostgresenvPGPASSWORD="${MASTER_PASS}"nohup${PG_BIN}/pg_basebackup\-h${MASTER_HOST}-p5432-U${MASTER_USER}-D${PG_DATA}-P-R-Xstream\>/tmp/pg_basebackup.log2>&1&echo"PID:$!"# 4. 看日志echo"tail -f /tmp/pg_basebackup.log 看进度"# 5. 起库sudo-upostgres${PG_BIN}/pg_ctl start-D${PG_DATA}echo"从库已启动，确认："sudo-upostgres${PG_BIN}/psql-c"SELECT * FROM pg_stat_wal_receiver;"

文档日期：2026-06-25
适用：PG 13 pg_basebackup 重建从库