| From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
|---|---|
| To: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [External] Re: WAL Replication query |
| Date: | 2022-11-02 05:54:06 |
| Message-ID: | 54ba769f-7361-5df9-75fa-43669faf701e@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On 11/1/22 23:00, KK CHN wrote:
[snip]
> So there will be an inconsistency in the data between the current
> Primary ( promoted standby) and my recovered /repaired old server (
> which was primary before the crash).
>
> How to handle this data inconsistency or what best mechanism needs to
> be implemented if you were me in this use case scenario?
Before promoting Secondary to New Primary, I'd record it's current
pg_stat_replication.replay_lsn value somewhere and then compare it to the
relevant LSN on Old Primary when it comes back up.
If they're the same, then there's no data inconsistency.
If there is, then you've got to manually check tables, since every
application and database structure is different
--
Angular momentum makes the world go 'round.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2022-11-02 06:11:05 | Re: [External] Re: WAL Replication query |
| Previous Message | KK CHN | 2022-11-02 04:00:54 | Re: [External] Re: WAL Replication query |