[pgpool-general: 7077] Re: Rebooting the cluster?
ptim007 at yahoo.com
Fri Jun 5 22:58:59 JST 2020
If you have the archived wals, then yes I think it is possible to resynchronize the standby database using the archives. But I guess it will not be out-of-the-box, maybe you'll need to copy the archived WAL to the standby so that it can consume them to catch-up with the primary ? It is worth experimenting.
Also in the past I looked at a tool called barman, it can be very helpful (https://www.pgbarman.org/)
I am not using postgres for the moment so I don't know the latest technologies and I am not the best person to respond !
On Friday, June 5, 2020, 01:28:02 PM GMT+2, Anssi Kanninen <anssi at iki.fi> wrote:
Thanks again for valuable advice to this novice. :-)
If I use continous archiving (for point-in-time decovery) anyway, this
does not matter so much does it?
On Fri, 5 Jun 2020, Pierre Timmermans wrote:
> if you don't drop the replication slot, then the primary will accumulate the wal and the
> risk is a disk full. That's the difficulty about replication slots, it is a good feature
> but you need to monitor them. If you drop the replication slot, then you will probably have
> to rebuild the standby when it comes back, since there is a risk that not all wal will
> still be available on the primary.
> On Friday, June 5, 2020, 8:54:41 AM GMT+2, Anssi Kanninen <anssi at iki.fi> wrote:
> Thank you for the answer, Pierre! I'll try that also.
> Is there any downside on not dropping the replication slots at all? If I
> create them once on the primary and let them be there until other node is
> promoted as primary?
> - Anssi
> On Fri, 5 Jun 2020, Pierre Timmermans wrote:
> > Hi
> > Another solution is to change the startup script of pgpool so that the start of pgpool is
> > delayed until all the databases are up. So loop trying to connect to each backend
> > until success, with a max timeout
> > Pierre
> > On Friday, June 5, 2020, 1:57:40 AM GMT+2, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> > >> There's a parameter called "auto_failback" which automatically
> > >> attaches a PostgreSQL standby node if it's safe. auto_failback is
> > >> available in 4.1 or later.
> > >
> > > Thank you again for quick answer!
> > >
> > > That works but requires some changes to the example failover.sh
> > > -script. The replication slot is dropped if standby node goes down. So
> > > to get auto_failback working, the replication slot must be recreated
> > > or not to be dropped at all.
> > True. Peng, what do you think?
> > Best regards,
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> > English: http://www.sraoss.co.jp/index_en.php
> > Japanese:http://www.sraoss.co.jp
> > _______________________________________________
> > pgpool-general mailing list
> > pgpool-general at pgpool.net
> > http://www.pgpool.net/mailman/listinfo/pgpool-general
> anssi at iki.fi
> pgpool-general mailing list
> pgpool-general at pgpool.net
anssi at iki.fi_______________________________________________
pgpool-general mailing list
pgpool-general at pgpool.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pgpool-general