PostgreSQL Replication之第四章 设置异步复制(6)

4.6 有效的清理和恢复结束

最近几年, recovery.conf 已经变得越来越强大了。早在初期(在 PostgreSQL 9.0之前), 仅有 restore_command 和一些 recovery_target_time 相关设置。更多的现代 PostgreSQL 版本提供了更多的东西,让您有机会以一个很好和专业的方式控制您的重放进程。

在本节中,您将学习有什么样的设置,您将怎样轻松地使用这些功能。

4.6.1 取得重启点的控制权

到现在为止,我们已经无限地归档了XLOG。就像在现实生活中,无限是一个引起麻烦的概念。正如John Maynard Keynes已经在他著名的书中所陈述,The General Theory of Employment, Interest, and Money:

"In the long run, we are all dead."

适用于Keynes的激励的东西对于XLOG归档同样是如此;您根本无法继续做下去。在有些时候,XLOG必须被扔掉。为了使清理更容易,您可以放一个archive_cleanup_command到recovery.conf中。就像大多数其他命令,(例如,restore_command),则是以通用的shell脚本。您会把该脚本放在这里,该脚本将在每个重启点被执行。那么,什么是重起点?每次PostgreSQL从基于文件重放转换到基于流的重放,您就正在面对一个重起点。事实上,再次启动流复制被认为是一个启动点。

重起点一到达,您就可以让PostgreSQL执行一些清理程序(或任何其他东西)。清理掉旧的XLOG或触发一些通知是很容易的。

如下脚本显示了您如何清理掉任何一天前的XLOG:

#!/bin/sh

find /archive -mtime +1 -exec rm -f {} \;

请记住,您的脚本可以是任何复杂的类型。您必须决定一个适当的策略来处理XLOG。每个企业的情况是不同的,您可以灵活地控制您的归档和复制行为。

4.6.2 调整您的恢复结束

recovery_end_command提供和archive_cleanup_command类似的目的。当您的恢复(或XLOG流)已经完成,它会触发一些脚本执行。

同样,您可以用它来清理掉旧XLOG,发出通知,或执行任何其他想执行的操作。

时间: 2024-08-07 21:16:27

PostgreSQL Replication之第四章 设置异步复制(6)的相关文章

PostgreSQL Replication之第四章 设置异步复制(1)

执行完您的第一个即时恢复(PITR,Point-In-Time-Recovery),我们准备在一个真正的复制设置上工作.在本章,您将学会如何设置异步复制和流.我们的目标是确保您可以实现更高的高可用和更高的数据安全性. 在本章,我们将讨论以下主题: • 配置异步复制 • 理解流 • 合并流和归档 • 管理时间线 在本章的最后,您将很容易地在几分钟内设置流复制. 4.1 设置流复制 在前面章节中,我们已经从简单的16MB XLOG文件做了恢复.从逻辑上讲,重放进程一次只能重放16MB.这在您的复制设

PostgreSQL Replication之第四章 设置异步复制(2)

4.2 配置级联复制 正如您在本章已经看到的,设置流复制真的很容易.只需要设置几个参数,做一个基础备份,并享受您的复制设置. 在许多情况下,这种情况更有一点点微妙.在这个例子中我们假设:我们要使用一个master传送数据到几十台服务器.复制的开销其实很小(通常的说法是一个slave的开销是3%左右),但是您做小的事情是足够了,它仍然可能是一个问题.对100个 slave来说这绝对没有任何益处. 另一个用例是一个地方的master和在 另一个地方的多个slave.一遍又一遍地长距离发送大量的数据是

PostgreSQL Replication之第四章 设置异步复制(4)

4.4 基于流和基于文件的恢复 生活并不总只是黑色或白色:有时也会有一些灰色色调.对于某些情况下,流复制可能恰到好处.在另一些情况下,基于文件复制和PITR是您所需要的.但是也有许多情况下,您既需要流复制,也需要基于文件的复制.一个例子是:当您较长一段时间中断复制,您可能想再次使用归档来重新同步(resync)slave,而不是再次执行完全的基础备份.这也可能是有用的---保留一个归档一段时间以后调查或重放操作.好消息是PostgreSQL允许您混合基于文件和基于流的复制.您没有必要决定基于流的

PostgreSQL Replication之第四章 设置异步复制(7)

4.7 冲突管理 在PostgreSQL中,流复制数据仅在一个方向流动.XLOG由master提供给几个slave,这些slave消耗事务日志并为您提供一个较好的数据备份.您可能想知道这怎么会导致冲突,这会发生冲突. 考虑一下情形:如您所知,数据复制有很小的延迟.因此,XLOG在由master产生之后结束于slave.这微小的延迟会引起如下图所示的情景: 我们假设一个slave开始读取一个表.它是一个长读操作.与此同时,master收到一个请求,实际地删除那个表.这有一点问题,因为slave仍然

PostgreSQL Replication之第四章 设置异步复制(5)

4.5 使流复制更健壮 当连接到master时,slave要做的第一件事情是赶上master.但是,这会一直工作吗?我们已经看到,我们可以使用由基于流和基于文件组成的混合设置.这给了我们一些额外的安全性,以防流不工作. 在现实世界的场景中,传送XLOG的两种方法可能过于复杂.在许多情况下,使用流就足够了.问题的关键是:在一个正如已经描述过的正常的设置中,只要不再需要XLOG来修复master,master就可以丢掉XLOG.根据您的检查点配置,XLOG可能存在相当长一段时间,或只有很短的时间.麻

PostgreSQL Replication之第四章 设置异步复制(3)

4.3 slave到master的切换 如果您想扩展读或您想做一个数据备份,一个 slave是件美好的事情.但是,slave可能不会一直是slave.在有些时候,您可能需要把slave转换为master.PostgreSQL提供了一些简单的方法来做到这一点.第一个也是最有可能的最便捷的方法把一个slave转换为一个master是使用pg_ctl: iMac:slavehs$ pg_ctl -D . promote server promoting iMac:slavehs$ psql test

PostgreSQL Replication之第五章 设置同步复制(1)

到目前为止,我们已经处理了基于文件的复制(或日志传送)和简单的基于流复制的设置.在两种情况中,在master上事务被提交之后,数据被提交,由slave接收.在master提交和slave实际上完全地接收到数据这段时间,它仍然会丢失. 在本章中,我们将学习如下主题: • 确保没有任何事务丢失 • 配置PostgreSQL同步复制 • 理解并使用application_name • 同步复制的性能影响 • 复制的速度优化 5.1 设置同步复制 正如前面提到的,同步复制已经被用来尽一切花费来保护您数据

PostgreSQL Replication之第五章 设置同步复制(2)

5.2 理解实际影响和性能 在本章中,我们已经讨论了实际影响以及性能影响.但是,有什么好的理论性的例子吗?让我们做一个简单的基准测试,看看复制是怎么做的.我们做这样的测试来为您显示各种耐久性的级别不只是一个次要的话题,对性能来说它们是关键的. 让我们假设一个简单的测试:在下面的场景中,我们已经连接到两个同样强大的机器(3 GHz, 8 GB RAM) 超过1 Gbit 的网络.两台机器彼此相邻.为了演示同步复制的影响,我们使用 shared_buffers 和所有其他内存参数的默认设置,仅仅把

PostgreSQL Replication之第五章 设置同步复制(3)

5.3 冗余和停止复制 谈到同步复制,有一个现象一定不能被遗漏.想象一下,我们有一个同步复制的双节点集群.如果slave故障会发生什么?答案是master不能容易地区分慢slave和故障slave,因此它将开始等待slave回来. 乍一看,这看起来像废话,但是如果您再深入地想想.您会明白,它实际上是唯一正确的事情.如果有人使用同步复制,系统中的数据一定都是有价值的,所以它决不能有风险.拒绝数据和向终端用户反馈比使数据存储在风险和默默地忽视高耐久性需求要好. 如果您决定使用同步复制,您必须考虑在您