Re: pg_stat_replication became empty suddenly

From: "ascot(dot)moss(at)gmail(dot)com" <ascot(dot)moss(at)gmail(dot)com>
To: Jerry Sievers <gsievers19(at)comcast(dot)net>
Cc: "ascot(dot)moss(at)gmail(dot)com" <ascot(dot)moss(at)gmail(dot)com>, PostgreSQL general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_stat_replication became empty suddenly
Date: 2013-08-07 03:35:07
Message-ID: FDE6E6E5-860E-424F-A58C-213AEFBC042F@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks. I increased the wal_keep_segments and it works well now.

On 7 Aug 2013, at 12:43 AM, Jerry Sievers wrote:

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

Browse pgsql-general by date

  From Date Subject
Next Message BladeOfLight16 2013-08-07 04:00:41 Staging Database
Previous Message liuyuanyuan 2013-08-07 02:48:04 Re: inserting huge file into bytea cause out of memory