主页 / dba / 问题 / 98752
Accepted
davegreen100
Asked: 2015-04-24 23:43:17 +0800 CST

备份后备用服务器上缺少 WAL 文件

  • 772

我的 postgres 备份/恢复到待机似乎有间歇性问题

Postgres，是在 red hat 6 企业版上运行的 9.2 版

我有一个生产服务器 (PROD1) 和一个热备用服务器 (STANDBY1)，周日晚上我有一个脚本将 PROD1 置于备份模式，在 $PGDATA 目录上执行 tar，将文件复制到 STANDBY1，STANDBY1 上的脚本是然后调用以停止 STANDBY1 上的 postgres，解压缩 tar，然后再次启动 postgres。

与此同时，PROD1 上的 archive_command 继续在 STANDBY1 上复制 WAL 文件，因此理论上 STANDBY1 将被更新。然后在一周的剩余时间里应用 WAL 文件，直到下个星期日该过程再次开始。

PROD1 上备份脚本的代码提取

psql -X -U postgres --set ON_ERROR_STOP=on <<PSQL
select pg_start_backup('${WEEK_START}_DataBackup','true');
PSQL

tar -zcf $WEEKLYBACKUP_DIRECTORY/full_backup_${WEEK_START}.tar.gz --exclude=$PGDATA/pg_xlog/* --exclude=$PGDATA/pg_xlogArchive/* 
--exclude=$PGDATA/pg_xlogRestored --exclude=$PGADTA/postmaster.pid --exclude=$PGDATA/postmaster.opts $PGDATA/

psql -X -U postgres --set ON_ERROR_STOP=on <<PSQL
select pg_stop_backup();
PSQL

scp -p $WEEKLYBACKUP_DIRECTORY/full_backup_${WEEK_START}.tar.gz $DR_SERVER:$WEEKLYBACKUP_DIRECTORY/.

ssh -T $DR_SERVER <<EOF >> $MAILFILE
  cd /var/lib/pgsql/Scripts
  ./postgres-hotStandby $WEEK_START Y
EOF

STANDBY1 上的 hotstandby 脚本的代码提取

pg_ctl stop -D $PGDATA -m i >> $LOGFILE
tar -zxf $WEEKLYBACKUP_DIRECTORY/full_backup_${RESTORE_WEEK}.tar.gz

# create a recovery file
echo "standby_mode = 'on'" >$PGDATA/recovery.conf
echo "primary_conninfo = 'host=${LIVE_SERVER}'" >>$PGDATA/recovery.conf
echo "restore_command = 'cp -f $PGDATA/pg_xlog/%f $PGDATA/pg_xlogRestored'" >>$PGDATA/recovery.conf
echo "trigger_file = '${PGDATA}/failover'" >>$PGDATA/recovery.conf
sed -i 's/#hot_standby = off/hot_standby = on/g' $PGDATA/postgresql.conf
pg_ctl -w -D $PGDATA start

上述过程每秒钟运行一次，其他时间失败，给出消息

“psql: FATAL: 数据库系统正在启动”

当我尝试进入 psql 时。

查看 STANDBY1 上的日志文件，postgres 正在等待它说的 WAL 文件......

cp：无法统计`/vol2/postgres92/pgsql/data/pg_xlog/000000010000005200000003'：没有这样的文件或目录 2015-04-24 00:10:40 EDT -LOG：流复制成功连接到主 2015-04-24 00 :10:40 EDT -FATAL：无法从 WAL 流接收数据：FATAL：请求的 WAL 段 000000010000005200000003 已被删除

运行时pg_start_backup，这将创建一个发送到 STANDBY1 的 WAL 文件（例如 000000010000005200000003），并且在pg_stop_backup运行时会创建一个备份 WAL 的结尾（例如 000000010000005200000003.00000020.backup），该文件也正确发送到 STANDBY1。但是当失败发生时， pg_start_backup WAL 似乎在 STANDBY1 服务器上丢失了。

希望这一切对某人有某种意义，任何想法出了什么问题？我似乎无法在我的测试系统上重现这一点，我认为这可能是一个时间问题，因为 PROD1 和 STANDBY1 的大小和位置，服务器之间的 scp 需要 15 分钟。

谢谢你提供的所有帮助

postgresql postgresql-9.2

1 个回答

  1. Best Answer

    这部分生成recovery.conf是可疑的：

    echo "restore_command = 'cp -f $PGDATA/pg_xlog/%f $PGDATA/pg_xlogRestored'" >>$PGDATA/recovery.conf

    似乎这件事的来源和目的地restore_command颠倒了。

    将您的示例与Continuous archiving中文档中的示例进行比较：

    restore_command = 'cp /mnt/server/archivedir/%f %p'

    恢复必须从存档目录（通常在 DBA 外部$PGDATA并完全由 DBA 控制）复制到$PGDATA/pg_xlog（由 扩展%p）。

    我假设那$PGDATA/pg_xlogRestored是您的存档目录，因为我看不出它可能是什么。就我个人而言，原则上我会把它放在外面，$PGDATA但这不是强制性的。

    • 1

相关问题