Re: pg_stat_replication became empty suddenly
От | Jerry Sievers |
---|---|
Тема | Re: pg_stat_replication became empty suddenly |
Дата | |
Msg-id | 871u66kbwz.fsf@comcast.net обсуждение исходный текст |
Ответ на | Re: pg_stat_replication became empty suddenly ("ascot.moss@gmail.com" <ascot.moss@gmail.com>) |
Ответы |
Re: pg_stat_replication became empty suddenly
|
Список | pgsql-general |
"ascot.moss@gmail.com" <ascot.moss@gmail.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.consulting@comcast.net p: 312.241.7800
В списке pgsql-general по дате отправления: