6.4 处理监控工具 还有几个监控工具可以使您的日常生活更轻松. 其中最流行的监控工具是Nagios.它被广泛地使用,也支持各种软件组件. 要使用 Nagios 来监控您的 PostgreSQL 集群,需要安装一个方面运行复制相关测试的插件.这样的适用于PostgreSQL 的插件可以自由地从 http://bucardo.org/wiki/Check_postgres下载.适用于 Nagios的一个插件Burcardo不仅能够用于测试复制,而且还是一个监控 PostgreSQL 的标准软件组件…

在本书的前几章,您已经学习了各种复制以及如何配额制各种类型的场景.现在是时候通过增加监控来让您的设置更加可靠了. 在本章中,您将学习监控什么以及如恶化实施合理的监控车辆.您将学习: • 检查您的 XLOG 归档 • 检查 pg_stat_replication 系统视图 • 检查操作系统级别复制相关的进程 在本章的最后您应该能够正确地监控任何类型的复制设置. 6.1 检查您的归档 如果您计划使用即时恢复(PITR, Point-In-Time-Recovery)或如果您想使用XLOG归档来帮助您…

6.2 检查pg_stat_replication 检查归档以及 archive_command主要用于即时恢复( PITR,Point-In-Time- Recovery).如果您想监控一个基于流的设置,建议您 注意系统上称作pg_stat_replication的视图.此视图包含以下信息: test=# \d pg_stat_replication View "pg_catalog.pg_stat_replication" Column | Type | Modifiers ---…

6.3 检查操作系统进程 一旦我们检查了归档以及我们的系统视图,我们就准备检查系统 进程.检查系统进程可能看起来有点粗糙,但它被证明非常有效. 在master上,我们可以简单地检查一个名为wal_sender的进程.在slave上我们要检查一个名为 wal_receiver的进程. 让我们首先检查一下我们应该在master上看到什么: 9314 ?? Ss 0:00.00 postgres: wal sender process hs ::1(61498) idle 在Linux上我们可以看到那…

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

13.3 聪明地扩展与处理集群 建立集群不是您面临的唯一任务.如果所有的事情都做完了并且系统已经运行了,您可能需要到处调整配置. 13.3.1 添加和移动分区 一旦一个集群启动并运行,您可能会发现您的集群太小,而不能处理您的应用产生的负载.现在的问题是:如何采用最明智的方法做到这一点? 您可以做的最好的事情是创建比需要的多的多的分区.所以,如果您开始考虑使用差不多四个节点,我们直接创建十六个,每台服务器上运行四个分区.在这种情况下,扩展您的集群将会很容易: • 复制所有的生产节点 • 重新配置…

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

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

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

3.4 重放事务日志 一旦我们创建了一个我们自己的初始基础备份,我们可以收集数据库创建的XLOG.当时间到时,我们可以使用所有这些XLOG 文件并执行我们所期望的恢复进程.这就像本节描述的一样工作. 执行基本恢复 在PostgreSQL中,整个恢复过程有一个称为recover.conf的文件管理,其主要驻留在基础备份的主目录中.在启动的时候被读取,并告诉数据库服务器到哪里可以找到XLOG归档,什么时候终止重放,等等. 为了让您开始恢复,我们决定为执行一个基本的备份过程包含一个简单的recover…