7.3. 复制节点状态监控

所述为什么监察有关的事宜，监视 BDR 组中的对等节点的状态至关重要。有用于此目的的两种主要观点︰ pg_stat_replication 要监视其积极复制节点和 pg_replication_slots 要监视其复制插槽进展。 7.3.1.监测使用 pg_stat_replication 连接的同行

管理员可以查询 pg_catalog.pg_stat_replication 以监视主动复制连接。它显示的本地端的连接 （WAL发件人过程），pid 由同行发送应用程序的名称 （为 BDR，这是 bdr （sysid、 时间线、 dboid，）），和其他状态信息︰

    SELECT * FROM pg_stat_replication;
      pid  | usesysid | usename |              application_name              | client_addr | client_hostname | client_port |         backend_start         | backend_xmin |   state   | sent_location | write_location | flush_location | replay_location | sync_priority | sync_state
    -------+----------+---------+--------------------------------------------+-------------+-----------------+-------------+-------------------------------+--------------+-----------+---------------+----------------+----------------+-----------------+---------------+------------
     29045 |    16385 | myadmin   | bdr (6127682459268878512,1,16386,):receive |             |                 |          -1 | 2015-03-18 21:03:28.717175+00 |              | streaming | 0/189D3B8     | 0/189D3B8      | 0/189D3B8      | 0/189D3B8       |             0 | async
     29082 |    16385 | myadmin   | bdr (6127682494973391064,1,16386,):receive |             |                 |          -1 | 2015-03-18 21:03:44.665272+00 |              | streaming | 0/189D3B8     | 0/189D3B8      | 0/189D3B8      | 0/189D3B8       |             0 | async

此视图显示所有活动的复制连接，不只是那些利用 BDR。以及你会看到连接从物理流副本、 其他逻辑解码解决方案等在这里。

要告诉如何远远落后于给定的活动连接，比较其 flush_location （重放位置的它已经承诺其工作） 与发送服务器 pg_current_xlog_insert_location() 使用 pg_xlog_location_diff，例如︰

     SELECT
       pg_xlog_location_diff(pg_current_xlog_insert_location(), flush_location) AS lag_bytes,
       pid, application_name
     FROM pg_stat_replication;

此查询将显示滞后下游服务器从上游服务器运行的查询会有多大。您不能使用这来看，从下游服务器，它背后上游它收到是多远。此外，该查询将显示所有复制对于消费者来说，包括非 BDR 的滞后。若要显示只有 BDR 同行，将追加在哪里 application_name 像 'bdr %'。

警告

pg_stat_replication 不显示同行有一个槽，但当前没有连接，虽然这种同行正仍保留WAL的服务器。它是监测 pg_replication_slots 太重要。

目前还没有任何设施多么落后给定节点的报告在经过墙上时钟时间的秒。所以你不能轻易告诉该节点 X 目前已是 n 秒以上节点 Y 上的原始数据的数据。如果这是一项应用程序要求应用程序应该定期时间戳刻度线记录写入表并检查如何老给定节点的最新的刻度线是在其他节点上。

7.3.2.复制插槽状态监视

有关复制插槽(逻辑和物理)的信息是在 pg_catalog.pg_replication_slots 视图中可用。此视图显示所有插槽，使用它们活动的复制连接。 它看起来像︰

    SELECT * FROM pg_replication_slots;
                    slot_name                | plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn
    -----------------------------------------+--------+-----------+--------+----------+--------+------+--------------+-------------
     bdr_16386_6127682459268878512_1_16386__ | bdr    | logical   |  16386 | bdrdemo  | t      |      |          749 | 0/191B130
     bdr_16386_6127682494973391064_1_16386__ | bdr    | logical   |  16386 | bdrdemo  | t      |      |          749 | 0/191B130
    (2 rows)

如果插槽存在 active = t，那么就会有相应的 pg_stat_replication 条目 walsender 进程连接到插槽。

此视图显示只使用一个插槽的复制同步。 不要使用插槽的物理流的复制连接将不显示在这里，而只显示在 pg_stat_replication. BDR的复制是利用插槽完成的，因此所有 BDR 对等节点信息都会在这里显示。

若要查看多少额外的WAL BDR 插槽要求服务器保持，以字节为单位，使用类似的查询︰

    SELECT
      slot_name, database, active,
      pg_xlog_location_diff(pg_current_xlog_insert_location(), restart_lsn) AS retained_bytes
    FROM pg_replication_slots
    WHERE plugin = 'bdr';

保留的WAL不是添加剂;如果你有三个同龄人，其中需要 500 KB 的WAL要保留和一种需要 8 MB，则保留只有 8 MB。 这就像一个动态的版本的 wal_keep_segments 设置 （或，9.5，min_wal_size）。所以你需要监测以确保最大数额的留存WAL不排气中每个节点上的 pg_xlog 的可用空间。

pg_replication_slots.restart_lsn 不超前 pg_stat_replication.flush_location 是正常的。

插槽restart的位置并不表示你将看到对等节点的数据是多少岁。