【问题标题】:Postgresql Automatic archive purge not occuringPostgresql 自动归档清除未发生
【发布时间】:2015-07-10 17:12:33
【问题描述】:

我阅读了几篇关于 postgresql 存档恢复和清理的文档,但我的 postgresql 服务器仍然没有清除存档,或者我并不真正了解它是如何工作的。

简单地说,我为 WAL 归档清理编写了一个 shell 脚本。当我从命令行运行脚本时,它会工作并清除我的存档(我只留下三天后的存档)。我的脚本名为 pg_archive_cleanup,可执行并放在这里:/usr/sbin/

我像这样配置我的 /etc/postgresql/9.3/main/recovery.conf

# -------------------------------
# PostgreSQL recovery config file
# -------------------------------
#
# Edit this file to provide the parameters that PostgreSQL needs to
# perform an archive recovery of a database, or to act as a replication
# standby.
#
# If "recovery.conf" is present in the PostgreSQL data directory, it is
# read on postmaster startup.  After successful recovery, it is renamed
# to "recovery.done" to ensure that we do not accidentally re-enter
# archive recovery or standby mode.
#
# This file consists of lines of the form:
#
#   name = value
#
# Comments are introduced with '#'.
#
# The complete list of option names and allowed values can be found
# in the PostgreSQL documentation.
#
#---------------------------------------------------------------------------
# ARCHIVE RECOVERY PARAMETERS
#---------------------------------------------------------------------------
# archive_cleanup_command
#
# specifies an optional shell command to execute at every restartpoint.
# This can be useful for cleaning up the archive of a standby server.
#
archive_cleanup_command = '/usr/sbin/pg_archive_cleanup'
#
#---------------------------------------------------------------------------
# RECOVERY TARGET PARAMETERS
#---------------------------------------------------------------------------
#
# By default, recovery will rollforward to the end of the WAL log.
# If you want to stop rollforward at a specific point, you
# must set a recovery target.
#
# You may set a recovery target either by transactionId, by name,
# or by timestamp. Recovery may either include or exclude the
# transaction(s) with the recovery target value (ie, stop either
# just after or just before the given target, respectively).
#
#
#recovery_target_name = ''      # e.g. 'daily backup 2011-01-26'
#
#recovery_target_time = ''      # e.g. '2004-07-14 22:39:00 EST'
#
#recovery_target_xid = ''
#
#recovery_target_inclusive = true
#
#
# If you want to recover into a timeline other than the "main line" shown in
# pg_control, specify the timeline number here, or write 'latest' to get
# the latest branch for which there's a history file.
#
#recovery_target_timeline = 'latest'
#
#
# If pause_at_recovery_target is enabled, recovery will pause when
# the recovery target is reached. The pause state will continue until
# pg_xlog_replay_resume() is called. This setting has no effect if
# hot standby is not enabled, or if no recovery target is set.
#
#pause_at_recovery_target = true
#
#---------------------------------------------------------------------------
# STANDBY SERVER PARAMETERS
#---------------------------------------------------------------------------
#
# standby_mode
#
# When standby_mode is enabled, the PostgreSQL server will work as a
# standby. It will continuously wait for the additional XLOG records, using
# restore_command and/or primary_conninfo.
#
standby_mode = on
restore_command = 'cp /var/lib/postgresql/database/archive/%f "%p"'
#
# primary_conninfo
#
# If set, the PostgreSQL server will try to connect to the primary using this
# connection string and receive XLOG records continuously.
#
primary_conninfo = 'host=db-master port=5432 user=repli password=Esibfegiav4'           # e.g. 'host=localhost port=5432'
#
#
# By default, a standby server keeps restoring XLOG records from the
# primary indefinitely. If you want to stop the standby mode, finish recovery
# and open the system in read/write mode, specify path to a trigger file.
# The server will poll the trigger file path periodically and start as a
# primary server when it's found.
#
trigger_file = '/var/lib/postgresql/database/failover_trigger'
#
#---------------------------------------------------------------------------
# HOT STANDBY PARAMETERS
#---------------------------------------------------------------------------
#
# Hot Standby related parameters are listed in postgresql.conf
#
#---------------------------------------------------------------------------

你可以看到这条线

archive_cleanup_command = '/usr/sbin/pg_archive_cleanup'

我的清理脚本:

#!/bin/bash

ARCHIVEDIR='/var/lib/postgresql/database/archive'
CHECKPOINT=$(find $ARCHIVEDIR -type f -mtime +3 -type f -printf '%f\n' | sort -r | head -1)
cd $ARCHIVEDIR
/usr/bin/pg_archivecleanup $ARCHIVEDIR $CHECKPOINT

find $ARCHIVEDIR -type f -mtime +3 -a -type f -a ! -newer $CHECKPOINT -delete

但是 4 天后磁盘空间增加了。 我在文档中看到 recovery.conf 文件是在 check_pointrestart_point 读取的... 所以我想知道为什么档案没有自动清除?我在哪里设置发生率? postgresl 什么时候应该进行清除? 我希望这每天都发生,我有义务将我的清理脚本放在 crontab 中吗?或者别的地方? 而且我的 postgresql 日志文件中也没有任何痕迹。清理日志写在哪里?

感谢您的回复。

【问题讨论】:

  • 您的主服务器是否在其postgresql.conf 中设置了archive_command
  • 是的@CraigRinger 我的主人在ist postgresql.conf 中有一个archive_command 集。这里是:archive_command = 'rsync -aq %p postgres@db-slave:/var/lib/postgresql/database/archive/%f' db-slave 是从站的名称,我有 WAL 归档清除问题。

标签: postgresql wal


【解决方案1】:

pg_archivecleanup 接受参数:

$ /usr/pgsql-9.4/bin/pg_archivecleanup 
pg_archivecleanup: must specify archive location
Try "pg_archivecleanup --help" for more information.

如果您查看副本的日志,您可能会看到来自pg_archivecleanup 的重复帮助消息。

the manual 显示 archive_cleanup_command 具有 %r 替换最后一个有效重启点,并显示示例配置:

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

【讨论】:

  • 是的@Craig Ringer,但是如果您查看我在上面写的 pg_archive_cleanup,您应该会看到我将脚本中的参数传递给 pg_archivecleanup 之类的命令这个:/usr/bin/pg_archivecleanup $ARCHIVEDIR $CHECKPOINT 你的意思是我应该这样做:/usr/bin/pg_archivecleanup $ARCHIVEDIR $CHECKPOINT %r?是在master那边做的吗?谢谢
  • 我已经用 %r 参数更新了清理脚本。但是请在哪里真正看到清理日志? master和slave上都没有相关日志。
  • @papiveron 你的log_min_messages是什么?
【解决方案2】:

我解决了这个问题。

我的脚本和配置都很好。考虑到我的修改,我只是没有重新启动 postgresql 服务以获得新的重新启动点。

我确实重新启动了 servicec,它现在可以正常工作了。

感谢@Craig

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-05-27
    • 2012-11-08
    • 1970-01-01
    • 2014-05-05
    • 2015-12-02
    • 2017-01-13
    • 1970-01-01
    • 2019-12-03
    相关资源
    最近更新 更多