Re: Backup solution over unreliable network

Поиск
Список
Период
Сортировка
От Achilleas Mantzios
Тема Re: Backup solution over unreliable network
Дата
Msg-id 78d8f90a-7745-743f-53a2-547d6aa551c8@matrix.gatewaynet.com
обсуждение исходный текст
Ответ на Re: Backup solution over unreliable network  (David Steele <david@pgmasters.net>)
Ответы Re: Backup solution over unreliable network  (David Steele <david@pgmasters.net>)
Список pgsql-admin
Hello David, Stephen, All and HPNY

On 30/11/18 6:50 μ.μ., David Steele wrote:
> On 11/30/18 11:24 AM, Achilleas Mantzios wrote:
>> On 30/11/18 5:29 μ.μ., Stephen Frost wrote:
>
>>> We've had a few folks using pgbackrest to push to two stanzas by way of
>>> basically doing 'pgbackrest --stanza=a archive-push && pgbackrest
>>> --stanza=b archive-push' and with that it does work, and you could
>>> combine that with the max WAL setting, potentially, but it's not a
>>> solution that I'm really a fan of.  That's definitely a use-case we've
>>> been thinking about though and have plans to support in the future,
>>> but there are other things we're tackling now and so multi-repo hasn't
>>> been a priority.
>>
>> If we called with e.g. --archive-push-queue-max=50G for the unreliable stanza and let to default for the reliable
stanzathat would be OK, I guess. Yes I understand you'd like a more systematic 
 
>> approach to the problem, but for the moment do you see any potential risk in doing what you described?
>
> Multiple stanzas are tricky to configure if async archiving is in use, otherwise it is relatively straightforward. 
Youjust need two configuration files and each archive command will need one 
 
> explicitly configured (--config).
>
> If async archiving is enabled then each stanza will also need a separate spool directory.  This configuration has
neverbeen tested and I recommend against it.
 
Just tested finished backing up our 1.2T logical subscriber test node DB ! With a deliberate interrupt and with
--resume--process-max=4 and it worked just great!
 
On our production primary/physical standby cluster I want to retain our (primitive) local backup/archive functionality,
whichwe do via :
 
archive_command = /usr/bin/rsync -a --delay-updates %p sma:/smadb/pgsql/pitr/%f
and instead of using a second local pgbackrest repo, just combine archive_command asis with pgbackrest to the remote
repowith something like :
 
archive_command = /usr/bin/rsync -a --delay-updates %p sma:/smadb/pgsql/pitr/%f && pgbackrest --stanza=dynacom
--archive-push-queue-max=50Garchive-push %p
 

I read the code and saw that --archive-push-queue-max works even when not in async mode (default push). We are not
planningfor async at this early stage. Do you see and potential problem with the above?
 

>
> pgBackRest currently requires some files and all WAL to be sent from the primary even when doing backup from
standby. We may improve this in the future but it's not on the road map right now.
 

We are planning to backup from the physical standby, but as you said the archive_command would be running from the
primary.

>
> Regards,


-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt



В списке pgsql-admin по дате отправления:

Предыдущее
От: Ashif Shaikh
Дата:
Сообщение: How to set default owner of objects in Postgresql
Следующее
От: Guillaume Lelarge
Дата:
Сообщение: Re: How to set default owner of objects in Postgresql