| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | "Shukla, Pranjal" <pshukla(at)akamai(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Query on WAL Optimization and Streaming Replication |
| Date: | 2022-03-17 13:19:52 |
| Message-ID: | 311862d1f3cf8aa637d25f95a3434eb43bb4d35f.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 2022-03-17 at 12:36 +0000, Shukla, Pranjal wrote:
> uring upgrades of our application, we generally shutdown all Secondary servers
> which are getting stream replicated from Primary Servers. This is to maintain
> a copy of database on other servers should
> we wish to revert (of course we take DB Backups too before starting the activity).
> After the application upgrade is done, when we start the secondary, often the
> replication is broken, and we need to
> again setup using pg_basebackup. How do we ensure that secondary is able to
> resume the replication without the need of base back up again?
There are three ways:
1. have a WAL archive and configure "restore_command" on the standby
2. set "wal_keep_size" on the primary high enough
3. use a replication slot
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jayson Hreczuck | 2022-03-17 13:21:18 | Re: Apparently table locks are the key issue to see red flags |
| Previous Message | GoLang Developere | 2022-03-17 12:58:50 | High Postgres postmaster CPU when My Background Worker is loaded. |