Re: Investigate postgres 9.6.3 repmgr lag 4.0.4 - Mailing list pgsql-admin

From Flavio Henrique Araque Gurgel
Subject Re: Investigate postgres 9.6.3 repmgr lag 4.0.4
Date
Msg-id CAGHTAeOzne+6nXhOTpBRs_ggeZBc1yBhqv9_j1kdQQk=L=MGyw@mail.gmail.com
Whole thread Raw
In response to Re: Investigate postgres 9.6.3 repmgr lag 4.0.4  (Rui DeSousa <rui@crazybean.net>)
Responses Re: Investigate postgres 9.6.3 repmgr lag 4.0.4  (Ron <ronljohnsonjr@gmail.com>)
List pgsql-admin


Em dom, 24 de jun de 2018 às 17:32, Rui DeSousa <rui@crazybean.net> escreveu:


On Jun 24, 2018, at 4:59 AM, Mariel Cherkassky <mariel.cherkassky@gmail.com> wrote:


Now, How can I further investigate it ? my wal_keep_segment is assigned to 100 but since friday 261 wals were generated so I guess I dont have another option but to sync the node again. However, I want to understand why it happened. What can you advice me to check ?


What is the connectivity between the nodes, any firewalls?  What’s the settings for wal_sender_timeout and wal_receiver_timeout?  Why not use a replication slot or have it fail over to using the archived WALs instead of full database restore?

There should be other messages in Postgresql logs.


Actually there are just two simple questions for the OP: Why you're not running the latest 9.6 and why you're not using replication slots? 

Since you'll have to recreate the lost standby, I strongly recommend going for replication slots to avoid the situation of standby servers getting out of sync, you won't need to mess with wal_keep_segments anymore.

Flavio Gurgel

pgsql-admin by date:

Previous
From: Rui DeSousa
Date:
Subject: Re: Investigate postgres 9.6.3 repmgr lag 4.0.4
Next
From: Ron
Date:
Subject: Re: Investigate postgres 9.6.3 repmgr lag 4.0.4