[pgpool-general: 7077] Re: Rebooting the cluster?

Pierre Timmermans 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 !

Pierre 

    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?

Cheers,
  - Anssi

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.
> 
> Pierre
> 
> 
> On Friday, June 5, 2020, 8:54:41 AM GMT+2, Anssi Kanninen <anssi at iki.fi> wrote:
> 
> 
> Hi,
> 
> 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?
> 
> Cheers,
>   - 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
> database
> > 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
> http://www.pgpool.net/mailman/listinfo/pgpool-general
> 
>

-- 
anssi at iki.fi_______________________________________________
pgpool-general mailing list
pgpool-general at pgpool.net
http://www.pgpool.net/mailman/listinfo/pgpool-general
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20200605/abc67e8c/attachment-0001.html>


More information about the pgpool-general mailing list