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

4.5 使流复制更健壮

当连接到master时,slave要做的第一件事情是赶上master。但是,这会一直工作吗?我们已经看到,我们可以使用由基于流和基于文件组成的混合设置。这给了我们一些额外的安全性,以防流不工作。

在现实世界的场景中,传送XLOG的两种方法可能过于复杂。在许多情况下,使用流就足够了。问题的关键是:在一个正如已经描述过的正常的设置中,只要不再需要XLOG来修复master,master就可以丢掉XLOG。根据您的检查点配置,XLOG可能存在相当长一段时间,或只有很短的时间。麻烦的是:如果您slave连接到master,可能会出现的情况是期望的XLOG已经不再了;在这种情况下,slave不能重新同步自己。您可能会发现这有点恼人,因为它隐含地限制了您的 slave 到您的 master 检查点行为的最大停机时间。

很明显,这可能会导致生产系统上的问题。为了让您的设置更加健壮,我们建议大量使用wal_keep_segments。这个postgresql.conf设置的思想是让master 保持比理论上需要的更多的XLOG文件。如果您设置该变量为1000,它意味着master将保持16GB以上的XLOG。换句话说,您的slave相比平常可以消失16GB(就转换到master而言)。这极大地增加了slave无需从头开始完全同步自身而加入集群的优势。对于一个500MB的数据库这是不值得一提的,但是如果您的设置需要容纳数百G或T的数据,这是一个巨大的优势。产生一个20TB实例的基础备份是一个漫长的过程,您可能不想太频繁地这样做,您肯定不想一遍又一遍地这样做。

时间: 2024-10-14 22:02:53

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

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之第四章 设置异步复制(6)

4.6 有效的清理和恢复结束 最近几年, recovery.conf 已经变得越来越强大了.早在初期(在 PostgreSQL 9.0之前), 仅有 restore_command 和一些 recovery_target_time 相关设置.更多的现代 PostgreSQL 版本提供了更多的东西,让您有机会以一个很好和专业的方式控制您的重放进程. 在本节中,您将学习有什么样的设置,您将怎样轻松地使用这些功能. 4.6.1 取得重启点的控制权 到现在为止,我们已经无限地归档了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回来. 乍一看,这看起来像废话,但是如果您再深入地想想.您会明白,它实际上是唯一正确的事情.如果有人使用同步复制,系统中的数据一定都是有价值的,所以它决不能有风险.拒绝数据和向终端用户反馈比使数据存储在风险和默默地忽视高耐久性需求要好. 如果您决定使用同步复制,您必须考虑在您