| From: | Rui DeSousa <rui(at)crazybean(dot)net> |
|---|---|
| To: | Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com> |
| Cc: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Investigate postgres 9.6.3 repmgr lag 4.0.4 |
| Date: | 2018-06-27 15:34:14 |
| Message-ID: | 2E8EE382-0E75-4919-87CF-5EABCD26D3F3@crazybean.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
> On Jun 27, 2018, at 6:02 AM, Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com> wrote:
>
> Hi all,
> it happened again. The weird thing is that when I query pg_stat_replication I see only one slave(the one that is still synced) and I dont see the second one. Moreover, I dont see anything in the repmgr log of the primary and in the slave regarding the disconnection...
>
Right, once it drops out of replication it no longer shows up in pg_stat_replication — it is a live view of current active connections.
Does the replica report that the WAL has already been removed from primary? If so most likely due to a spike in WAL file generation where the setting wal_keep_segment is too low; However, I’m still confused about your setup. Is the replica on the same subnet and what is the network usages? Any large activity happening on the system, i.e. index rebuilds? How many WALs where generated when the replica dropped out?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jerry Sievers | 2018-06-27 15:41:02 | Re: Investigate postgres 9.6.3 repmgr lag 4.0.4 |
| Previous Message | Colin Beckingham | 2018-06-27 14:40:44 | Bytea data in SQL output pane |