| 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: | Whole Thread | Raw Message | 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? |