在本书的前几章，您已经学习了各种复制以及如何配额制各种类型的场景。现在是时候通过增加监控来让您的设置更加可靠了。
在本章中，您将学习监控什么以及如恶化实施合理的监控车辆。您将学习：
• 检查您的 XLOG 归档
• 检查 pg_stat_replication 系统视图
• 检查操作系统级别复制相关的进程
在本章的最后您应该能够正确地监控任何类型的复制设置。
6.1 检查您的归档
如果您计划使用即时恢复(PITR, Point-In-Time-Recovery)或如果您想使用XLOG归档来帮助您的流设置，各种事情都可能出错，例如：
• 传送XLOG 可能失败
• 清理存档可能失败
6.1.1 检查archive_command
一个失败的 archive_command 可能是您的设置中的最大的搅局者之一。
archive_command 的思想是传送 XLOG到一些归档并在那里存储数据。但是，如果由于某些原因这些XLOG不能被传送会发生什么？
答案很简单：master必须保持这些XLOG文件，以确保没有XLOG文件丢失。必须始终有一个不间断的XLOG文件的序列-如果序列文件中有一个文件丢失，您的slave将不能被恢复。例如，如果您的网络发生故障，master将积累这些文件并保留它们。从逻辑上讲，不能永远这样做，因此，在有些时候，您将面临您的master服务器磁盘空间不足的问题。
这是很危险的，因为您正在用尽您的磁盘空间，没有办法保持写入到数据库。尽管读取仍然是可能的，大多数的写肯定会亏失败，并会严重干扰您的系统。PostgreSQL不会失败，在一个磁盘被填满之后您的实例将完好无损，但是，正如之前所说的，您的服务将被中断。
为了防止这种事情 发生，建议监控您的pg_xlog目录并检查：
• 异常地高数量的XLOG文件
• 托管pg_xlog分区的可用磁盘空间
这里的核心问题是：检查出来的什么数字才是一个合理的数字？在PostgreSQL的标准配额制中不应该使用超过checkpoint_segments * 2 + wal_keep_segments这么多的XLOG文件。如果XLOG文件数开始大规模地增长，您会遇到一些奇怪的问题。
确保archive_command正常工作。
如果您正确地执行这些检查，在这方面不会发生不好的事情-如果您无法检查这些参数，您离危险就不远了。
6.1.2 监控事物日志归档
磁盘空间耗尽不只会发生在master上。同样的事情也会发生在您的归档上。所以，建议您也监控磁盘空间。
除了无论如何都要监控的磁盘空间，有一件事情您应该注意您的雷达。您必须拿出一个像样的策略来处理基础备份。请记住，只允许您删除比您想保存的最早的基础备份的XLOG还要早的XLOG。这个小东西会破坏您的磁盘空间监控。为什么呢？因为您必须保持一定量的数据，知道您正在耗尽磁盘空间是一件好事，但是就不能为之做点什么吗？强烈建议您确保您的归档有足够的备用容量。万一您的数据库系统需要写大量的事务日志，这是很重要的。