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

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

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

4.8 处理时间线 时间线是一个您必须要知道的一个重要的概念,尤其是当您规划一个大型的设置的时候. 那么,什么是时间线呢?事实上,它是XLOG的一个分支.正常情况下,刚设置的一个数据库实例使用的时间线号为1.我们假设,我们开始复制我们的master数据库到一个slave系统.slave也会在1号时间线处操作.有些时候,您的master可能会出现故障,您的 slave将被提升为一个新的master.这是当一个时间线切换发生时的时间.现在新的master将创建它自己的事务日志.从逻辑上讲,我们想确保…

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

4.6 有效的清理和恢复结束 最近几年, recovery.conf 已经变得越来越强大了.早在初期(在 PostgreSQL 9.0之前), 仅有 restore_command 和一些 recovery_target_time 相关设置.更多的现代 PostgreSQL 版本提供了更多的东西,让您有机会以一个很好和专业的方式控制您的重放进程. 在本节中,您将学习有什么样的设置,您将怎样轻松地使用这些功能. 4.6.1 取得重启点的控制权 到现在为止,我们已经无限地归档了XLOG.就像在现实生…

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

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…

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

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