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

[Anssi Kanninen]

Actually it will work automatically is restore_command is configured to use scp.

On June 5, 2020 4:58:59 PM GMT+03:00, Pierre Timmermans <ptim007 at yahoo.com> wrote:
>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
>  

-- 
Anssi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20200605/510d41e9/attachment.html>