Feedback about hybrid SAN snap and rsync'd approach for large systemcloning

Поиск
Список
Период
Сортировка
От Jerry Sievers
Тема Feedback about hybrid SAN snap and rsync'd approach for large systemcloning
Дата
Msg-id CB47B6F6-2619-4D79-97F2-412C840F2F32@comcast.net
обсуждение исходный текст
Ответы Re: Feedback about hybrid SAN snap and rsync'd approach for large systemcloning  (Laurenz Albe <laurenz.albe@cybertec.at>)
Re: Feedback about hybrid SAN snap and rsync'd approach for large systemcloning  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-general
Suppose we have a DB cluster with an additional tablespace and we are
able to make an atomic SAN snapshot of *only* the main cluster
volume...

The additional tablespace contains only UNLOGGED relations.

We cannot snap that volume so we use rsync as follows...

1. pg_start_backup('foo');
make SAN snapshot
rsync the add'l tablespace
pg_stop_backup()

Now provision a new cluster around the snapshot and rsync'd volume,
rejigger the pg_tblspc link if necessary... and start it up maybe or
not having it remain as a streaming replica.

It's been my experience that possibly bulky data in the additional
tablespace does *not* need be rsync'd if we capture only the *_init
files.

Id' be curious to here feedback re the sanity of this approach.

And would also like to know if perhaps *only* the directories under
the rsync'd tablespace actually must be present for a successful
recovery.

The above approach has worked mumerous times even with origin systems
having large, churny contents in the dedicated unlogged tablespace
(which is on a much faster local NVME volume than the main SAN
volume.)

Thanks!



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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: alter function/procedure depends on extension
Следующее
От: Adrian Ho
Дата:
Сообщение: Re: OpenSSL@1.1 not getting linked with Homebrew - trying to install postgresql