问题:
有没有办法告诉 Postgres (9.2)“将所有 WAL 文件合并pg_xlog
回非 WAL 数据文件,然后删除所有成功合并的 WAL 文件?”
我希望能够“强制”执行此操作;即checkpoint_segments
忽略归档设置。文件系统 WAL 缓冲区 ( pg_xlog
) 目录应清空或几乎清空。如果pg_xlog
目录占用的部分或全部空间随后被数据目录占用,则没问题;我们的 DBA 要求文件(即数据目录,而不是 sql)数据库备份没有任何积压的 WAL,但空间消耗不是问题。
在此操作期间,WAL 活动几乎为零是一个很好的约束。我可以确保在此过程中数据库服务器要么关闭,要么无法连接(零用户生成的事务负载)。
本质上,我希望 Postgres 暂时忽略归档/检查点保留策略,并将所有 WAL 活动刷新到核心数据库文件,使pg_xlog
数据库保持与最近创建时相同的状态 - 仅包含很少的 WAL 文件。
我尝试过的:
我知道该pg_basebackup
实用程序执行类似这样的操作(它生成一个几乎所有 WAL 合并的 Postgres 实例数据目录的副本),但我们还没有准备好在所有系统上使用它,因为我们仍在测试复制设置;我希望有一个更短期的解决方案。
我尝试过发出CHECKPOINT
命令,但它们只是回收一个 WAL 文件并将其替换为另一个(也就是说,如果它们确实执行任何操作;如果我在数据库空闲时间发出它们,它们什么也不做)。pg_switch_xlog()
同样,只是强制切换到下一个日志段;它不会刷新所有排队/缓冲的段。
我也使用过该pg_resetxlog
实用程序。该实用程序可以满足我的要求,但其所有使用文档似乎都表明它会破坏(而不是从事务日志中刷新到主数据文件中)部分或全部 WAL 数据。这种印象准确吗?如果不是,我可以pg_resetxlog
在零 WAL 活动期间使用它来强制将所有排队的 WAL 数据刷新为非 WAL 数据吗?如果答案是否定的,我该如何实现这一目标?
谢谢!
答案1
。。。有什么东西告诉我你的 DBA 不是 Postgres 专家?:-)
根据您的评论,最接近您正在寻找的解决方案的方法是启动数据库(使用您的基本备份)并发出CHECKPOINT
,然后关闭该数据库并备份它。这会将“追赶”日志中的 WAL 数据刷新到主数据库文件,并为您留下一个“空”的 WAL(尽管您仍然会有一些段挂起,这些段是实际启动服务器和验证一致性所必需的)。
确保您抓取的备份已将所有数据刷新到主数据库文件的唯一其他方法是关闭数据库进行备份。
我不建议对静态备份执行上述任何一项操作,但你似乎正在这样做。只需保留按照 Postgres 手册创建的备份,如果需要激活它,请按照手册中的常规操作使用它来启动服务器。
我真的想不出你的 DBA 提出请求的正当理由——Postgres 在命令后重播你收集的日志文件时的短暂启动延迟pg_stop_backup()
不值得做一些奇怪和不同的事情,而不是遵循手册中久经考验的程序,并且你需要进行大量测试来验证你想出的任何新程序是否与标准程序一样强大,在我看来,这是一个没有吸引力的选择。
显然,从属/流式/热备用的过程略有不同,同样按照手册操作。
如果您的 DBA真的想要最少数量的 WAL 段我建议使用以下解决方案:
- 指定一个从属主机作为备份主机。
- 当备份时间到来时,我们关闭从属服务器并进行文件系统备份
- 当我们完成备份时,从属服务器就会启动,通常会在 15 分钟内赶上。
从此备份进行恢复本质上与激活从属服务器相同——启动从属服务器并创建恢复触发文件。
设置此功能有几个技巧 - 手册中没有涵盖这些技巧,但显然你需要彻底测试。