From: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
---|---|
To: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
Cc: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_checksums? |
Date: | 2023-11-02 06:36:47 |
Message-ID: | CANNMO+LRS5JzkkNZZNZUkBc2zJgw=zg2sS9X3q5jPMYykm5VvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Oct 30, 2023 at 6:57 AM Alexander Kukushkin <cyberdemn(at)gmail(dot)com> wrote:
...
> As Michael already said, the following workflow works just fine (I did it dozens of times):
> 1. enable checksums on the standby node
> 2. start the standby and let it catch up with the primary
> 3. switchover to a standby node
> 4. enable checksums on the former primary (now replica).
There is also a good trick described in
https://www.crunchydata.com/blog/fun-with-pg_checksums to avoid
accidental start of Postgres:
after pg_ctl stop and before pg_checksums --enable, do:
mv data/pg_twophase data/pg_twophase.DO_NOT_START_THIS_DATABASE
and once pg_checksums --enable is done, move it back.
Additionally, I compiled some thoughts about running pg_checksums
without downtime (Patroni-friendly, of course) here:
https://twitter.com/samokhvalov/status/1719961485160689993.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomek | 2023-11-02 09:07:50 | Re: pg_dump/pg_restore --jobs practical limit? |
Previous Message | Ron | 2023-11-02 01:20:16 | Re: pg_dump/pg_restore --jobs practical limit? |