PostgreSQL Replication之第六章 监控您的设置(3)

6.3 检查操作系统进程

一旦我们检查了归档以及我们的系统视图,我们就准备检查系统 进程。检查系统进程可能看起来有点粗糙,但它被证明非常有效。

在master上,我们可以简单地检查一个名为wal_sender的进程。在slave上我们要检查一个名为 wal_receiver的进程。

让我们首先检查一下我们应该在master上看到什么:

9314 ?? Ss 0:00.00 postgres: wal sender process

hs ::1(61498) idle

在Linux上我们可以看到那个进程不仅有自己的作用 (在这种情况下, wal_sender),而且还带有终端用户的名字以及相关的网络连接信息。在我们的例子中我们可以看到已经有人从本地通过61498端口连接到了master。

slave上的情况是相当地简单:

9313 ?? Ss 0:00.00 postgres: wal receiver process

所有我们看到的是一个进程,告诉我们我们正在消耗XLOG。

如果这里有两个进程,您已经得到了一个很好的指标,您的复制设置工作的很好。

时间: 2024-10-26 14:18:48

PostgreSQL Replication之第六章 监控您的设置(3)的相关文章

PostgreSQL Replication之第六章 监控您的设置(4)

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

PostgreSQL Replication之第六章 监控您的设置(1)

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

PostgreSQL Replication之第六章 监控您的设置(2)

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 ---

深入浅出Zabbix 3.0 -- 第六章 监控项配置与管理

第六章 监控项配置与管理 Zabbix系统中监控项(Items)的定义和管理非常重要,所有的监控指标都是通过定义不同的监控项收集数据.Zabbix通过主机作为一个逻辑单元组织和管理监控项,所有的监控项都必须属于某个主机,且在同一主机中只能有一个唯一的监控项存在. 6.1监控数据 Zabbix 不同于与大多数其他监控解决方案的一个重要特征是Zabbix通过监控项从被监控对象收集的数据是原始数据,而不是告警或状态的更新数据.大多数监控方案中,不管是通过agent或其他方法收集到监控数据后,会对该数据

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

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

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

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

PostgreSQL Replication之第三章 理解即时恢复(4)

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

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

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

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

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