From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: HA Setup Review |
Date: | 2024-05-03 03:24:55 |
Message-ID: | CANzqJaB2tT_WxSVrNqhUqyXTm3h_u+wR5OLeJEhNA7K0jVAj1Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, Apr 30, 2024 at 12:30 PM akshay polji <akshay(dot)polji(at)gmail(dot)com>
wrote:
> ---- Point - 3
> "You can switch from async to sync replication just before patching, and
> then switch back to async when it's completed." --> I am a little confused
> here. What benefit do we get by switching from async to sync replication
> before patching?
>
The *guarantee* that all transactions committed on the primary have been
written to the secondary just before shutting down Primary.
> I mean that would block the transactions on the primary DB right?
>
Wrong 99.99% of the time. It *blocks* the transaction *IFF the network/WAN
link is down*.
When the WAN link is up, you "just" get cascading transaction
*slowness* because
of WAN latency.
Thus... you leave replication to the remote DR site in asynchronous mode
until that very specific point when you need to guarantee remote
consistency: *just before* you shut down the Primary for patching.
Once the Primary is patched, and replication is restored, then you can
change back to async mode.
From | Date | Subject | |
---|---|---|---|
Next Message | gunnar.wagner | 2024-05-03 05:06:24 | Re: postgresql in docker to improve security |
Previous Message | Kashif Zeeshan | 2024-05-03 03:23:01 | Re: postgresql in docker to improve security |