Re: pg_stat_replication became empty suddenly

From: "ascot(dot)moss(at)gmail(dot)com" <ascot(dot)moss(at)gmail(dot)com>
To: PostgreSQL general <pgsql-general(at)postgresql(dot)org>
Cc: ascot(dot)moss(at)gmail(dot)com
Subject: Re: pg_stat_replication became empty suddenly
Date: 2013-08-06 04:39:15
Message-ID: 57DC0F7E-C959-462D-874F-3EEA49702EC8@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

I found the problem should be because I tried to clean RAM cache in the slave by running "sync; echo 3 > /proc/sys/vm/drop_caches'
that caused the "receiver" of slave gone away.

ps -ef | grep receiver
postgres 6182 6178 0 12:11 ? 00:00:06 postgres: wal receiver process streaming D/FB8DA000
sync; echo 3 > /proc/sys/vm/drop_caches
ps -ef | grep receiver
root 8804 30447 0 12:29 pts/2 00:00:00 grep --color=auto receiver

regards

On 6 Aug 2013, at 10:44 AM, ascot(dot)moss(at)gmail(dot)com wrote:

> Hi,
>
> I am doing some stress tests to a pair of PG servers to monitor the pg_stat_replication, during the test, the pg_stat_replication suddenly became empty.
>
> PG version: 9.2.4
> O/S: Ubuntu: 12.04
>
> Since I need to monitor the replication lag from time to time, if the pg_stat_replication becomes empty, the lag calculation in the slave will be wrong.
> Please advise if this is a bug.
>
> regards
>
>
>
>
> How to reproduce:
>
> session 1: Master server - try to insert a large number of records into a test table
> postgres=# drop table test;CREATE TABLE test (id INTEGER PRIMARY KEY); INSERT INTO test VALUES (generate_series(1,100000000)); EXPLAIN ANALYZE SELECT COUNT(*) FROM test;
>
> 2) session 2: Master server - check the byte_lag from time to time
> postgres=# SELECT
> sent_offset - (
> replay_offset - (sent_xlog - replay_xlog) * 255 * 16 ^ 6 ) AS byte_lag
> FROM (
> SELECT
> client_addr,
> ('x' || lpad(split_part(sent_location, '/', 1), 8, '0'))::bit(32)::bigint AS sent_xlog,
> ('x' || lpad(split_part(replay_location, '/', 1), 8, '0'))::bit(32)::bigint AS replay_xlog,
> ('x' || lpad(split_part(sent_location, '/', 2), 8, '0'))::bit(32)::bigint AS sent_offset,
> ('x' || lpad(split_part(replay_location, '/', 2), 8, '0'))::bit(32)::bigint AS replay_offset
> FROM pg_stat_replication
> ) AS s;
> byte_lag
> ----------
> 2097216
> (1 row)
>
> postgres=# SELECT
>
> sent_offset - (
> replay_offset - (sent_xlog - replay_xlog) * 255 * 16 ^ 6 ) AS byte_lag
> FROM (
> SELECT
> client_addr,
> ('x' || lpad(split_part(sent_location, '/', 1), 8, '0'))::bit(32)::bigint AS sent_xlog,
> ('x' || lpad(split_part(replay_location, '/', 1), 8, '0'))::bit(32)::bigint AS replay_xlog,
> ('x' || lpad(split_part(sent_location, '/', 2), 8, '0'))::bit(32)::bigint AS sent_offset,
> ('x' || lpad(split_part(replay_location, '/', 2), 8, '0'))::bit(32)::bigint AS replay_offset
> FROM pg_stat_replication
> ) AS s;
> byte_lag
> ----------
> (0 rows)
>
>
> 3) session 3: Slave server -
> postgres=# SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp()) END AS log_delay;
> log_delay
> -----------
> 0
> (1 row)
>
> postgres=# SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp()) END AS log_delay;
> log_delay
> -----------
> 4.873282
> (1 row)
>
> .
> .
> .
> postgres=# SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp()) END AS log_delay;
> log_delay
> -------------
> 4070.325329
> (1 row)
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2013-08-06 04:49:48 Re: Seamless replacement to MySQL's GROUP_CONCAT function...
Previous Message ascot.moss@gmail.com 2013-08-06 02:44:00 pg_stat_replication became empty suddenly