|
Параметр restore_command
|
|||
---|---|---|---|
#18+
Добрый день. Нахожуь в процессе изучения физической репликации в PostgreSQL, возник вопрос по параметру "restore_command". Итак вот я настроил стриминговую репликацию, но так же сконфигурил постоянное архивирование wal'ов, на всякий случай. Вопрос: директория расположения для архивов, указанная в параметре archive_command = 'test ! -f /nfs/wal_arch/%f && cp %p /nfs/wal_arch/%f' на мастере должна быть расшеренной между мастером и репликой, верно? Для того чтобы в ситуации, когда реплика не может обратиться к Мастеру по протоколу репликации (сетевая проблема), она смогла посмотреть в каталог /nfs/wal_arch , который примаунчен к обоим серверам и накатывать изменения из архивов за счет команды в recovery.conf: restore_command = 'cp /nfs/wal_arch/%f %p'. А в том случае, если wal'лы архивируются на мастер сервере локально (в локацию не зашаренную с репликой) то в этом по сути нет никакого смысла, поскольку реплика не сможет оттуда ничего забрать в случае сетевых проблем с подключением к мастеру. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2021, 10:36 |
|
Параметр restore_command
|
|||
---|---|---|---|
#18+
Не надо писать базу, wal или архив wal на nfs вообще. Только если вы очень хорошо себе представляете, как этот самый nfs настраивать для durability. Базе и всей машинерии Log-Shipping standby абсолютно всё равно что вы делаете внутри restore_command. Ваша задача проста: положить требуемый сегмент WAL с именем %f в место %p. Откуда его брать - простор для творчества. s3-подобное хранилище, rsync, да хоть ssh на бекапный сервер Dr. Oracle А в том случае, если wal'лы архивируются на мастер сервере локально (в локацию не зашаренную с репликой) то в этом по сути нет никакого смысла, поскольку реплика не сможет оттуда ничего забрать в случае сетевых проблем с подключением к мастеру. Верно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2021, 11:00 |
|
|
start [/forum/topic.php?fid=53&fpage=16&tid=1994230]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
90ms |
get topic data: |
14ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
others: | 269ms |
total: | 448ms |
0 / 0 |