Re: pg_stat_replication became empty suddenly

From: Jerry Sievers <gsievers19(at)comcast(dot)net>
To: "ascot(dot)moss\(at)gmail(dot)com" <ascot(dot)moss(at)gmail(dot)com>
Cc: PostgreSQL general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_stat_replication became empty suddenly
Date: 2013-08-06 16:43:24
Message-ID: 871u66kbwz.fsf@comcast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"ascot(dot)moss(at)gmail(dot)com" <ascot(dot)moss(at)gmail(dot)com> writes:

> Hi,
>
> I just tried another round of tests, without running "sync; echo 3 > /proc/sys/vm/drop_caches',
> still got the same error, following FATAL errors are found in pg_log (slave), can anyone please advise how to resolve
> this error?
>
> regards
>
> LOG: entering standby mode
> LOG: consistent recovery state reached at 11/42000318
> LOG: redo starts at 11/42000280
> LOG: invalid record length at 11/42000318
> LOG: database system is ready to accept read only connections
> LOG: streaming replication successfully connected to primary
> FATAL: could not send data to WAL stream: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> LOG: unexpected pageaddr 10/D2EC0000 in log file 18, segment 5, offset 15466496
> LOG: streaming replication successfully connected to primary
> FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 000000010000001200000005 has already
> been removed
> LOG: streaming replication successfully connected to primary
> FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 000000010000001200000005 has already

Raise wal_keep_segments on your master configs ,and HUP and/or start
your standby a lot sooner after it's reloaded.

<snip>
>

--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 312.241.7800

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Travers 2013-08-06 16:49:06 Re: inserting huge file into bytea cause out of memory
Previous Message immersive.excel@gmail.com 2013-08-06 16:08:54 Re: Seamless replacement to MySQL's GROUP_CONCAT function...