Назад | Перейти на главную страницу

Настройка горячего резервирования Postgres в AWS

У нас есть база данных Posrgres 9.5, работающая на EC2 в AWS, и мы пытаемся настроить горячий резерв. На сервере содержится около 3 ТБ данных, поэтому резервное копирование - непростая задача.

Сначала я попытался создать базовую резервную копию для горячего резерва, запустив это руководство):

sudo -u postgres pg_basebackup -h <primary IP> -D /data/postgres -U repuser -v -P --xlog-method=stream

Дав ему поработать несколько часов, я решил, что на создание базовой резервной копии уйдет почти две недели. Я беспокоился, что к моменту его завершения на основном сервере не будет журналов WAL, датируемых 14 днями, поэтому я попробовал альтернативный метод.

Я выключил основной сервер на ночь и сделал снимок тома EBS. (Мы храним каталог данных на отдельном томе.) Затем я создал том из моментального снимка и подключил его к резервному.

На этом этапе как основной, так и резервный серверы отключены, и у них обоих есть совпадающие каталоги данных. Я запустил первичный канал, он явно подключился без проблем. Однако в режиме ожидания этого не произошло. Понадобилось немного покопаться, но я обнаружил эту ошибку в папке журнала (csv):

"hot standby is not possible because wal_level was not set to ""hot_standby"" or higher on the master server",,"Either set wal_level to ""hot_standby"" on the master, or turn off hot_standby here."

Уровень wal_level первичного сервера установлен на hot_standby. Я также обнаружил в Интернете, что эта ошибка может произойти, если резервный сервер просто не может подключиться к основному, но я проверил учетные данные, и они в порядке. (Они также отлично работали, когда я пытался использовать pg_basebackup.)

Итак, вот мой вопрос:

1) Почему не удалось сделать снимок основного и подключить его к резервному? Есть ли способ заставить его работать?

2) Если нет, есть ли более быстрый способ сделать резервную копию базы?

3) Если нет, будет ли на основном сервере достаточно данных WAL после завершения резервного копирования через 14 дней? Другими словами, сможет ли горячий резерв наверстать упущенное при запуске pg_basebackup?

Люк, в сообщении написано: "или выключите hot_standby здесь".

Разве это не так, в вашем резервном сервере (как это было из снапшота)?

Полагаю, ты не хочешь использовать патроны, Райт?

Если это не сработает, у меня нет простого ответа. Это будет зависеть от допустимого окна простоя, которое вы можете иметь, будь то одно приложение или мультитенантное, ...

Вы можете попробовать:

1) использовать pg_barman; 2) сначала выгрузите структуру, а затем попытайтесь выгрузить каждую таблицу отдельно, чтобы вы могли воспользоваться преимуществами использования большего количества ядер. 2.1) в этом сценарии ограничение будет io 2.2) Мне нужно больше времени, чтобы проанализировать использование FK, чтобы построить правильный последовательность 2.3) в этом случае я бы порекомендовал переименовать базу данных на некоторое время, чтобы новые данные не создавались 3) для сегментирования вашей базы данных

Удачи