From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Mariya Rampurawala <Mariya(dot)Rampurawala(at)veritas(dot)com> |
Cc: | "Ahmed, Nawaz (Fuji Xerox Australia)" <Nawaz(dot)Ahmed(at)aus(dot)fujixerox(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [EXTERNAL] RE: PostgreSQL-12 replication. Check replication lag |
Date: | 2020-08-06 02:39:42 |
Message-ID: | 20200806023942.GB16470@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Aug 05, 2020 at 06:36:15PM +0000, Mariya Rampurawala wrote:
> What I want to understand is that, in case of replication link
> failure, there will still be inserts happening at the master
> node. In that case, how will the slave know if it is up-to-date?
It cannot do that by itself, which is why in common HA scenarios you
have a witness host that acts as a monitoring instance for the primary
and the standby so as you limit SPOF issues. This depends of course
on your application requirements, but you can also leverage things
by using a replication lag in bytes on the primary, and even couple
that with synchronous replication to check when commits are getting
blocked.
IMO, I think that you should try to not reinvent the wheel and use one
of the solutions provided by the community, pg_auto_failover coming
into my mind as one solution for example.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Gauthier | 2020-08-06 14:01:21 | Can PAF be used to provide zero downtime while primary and backup servers are being patched? |
Previous Message | Thomas Munro | 2020-08-06 02:28:11 | Re: Check replication lag |