Всё верно, исправил. max_replication_slots предоставляет возможность больше не использовать wal_keep_segments, просто сделаем данное значение минимальным — 0.
Спасибо за комментарий.
archive_command = 'cd .' — ни критичен.
wal_keep_segments = 3000 — да можно сократить, я привел это как пример. Необходимо настроить под себя.
wal_keep_segments — задаёт минимальное число файлов прошлых сегментов журнала, которые будут сохраняться в каталоге pg_xlog, чтобы резервный сервер мог выбрать их при потоковой репликации. Источник
Спасибо за подсказку, я думаю что надо посмотреть в сторону интеграции barman в данную структуру, тем более что сами разработчики предлагают использование barman как один из вариантов.
Все запросы на запись-чтение должны идти через master ноду (haproxy+pgbouncer или просто pgbouncer), остальные standby ноды необходимо прописать на ноде с haproxy в режиме балансировки (roundrobin). Сами режимы(на какой ip только чтение, на какой чтение/запись) у нас реализованы на уровне приложений, т.е в коде приложений.
Нет не пробовали, мультимастер показывает худшую производительность при update и insert, чем данная схема c асинхронной репликацией или чем standalone Postgresql, хотя тоже имеет право на существование для определенных сервисов.
Дело в том, что при падении мастера автоматически происходит включение нового мастера(через промежуток времени, указанный в конфигах), соответственно существует риск того, что не все данные успели попасть на standby. Есть несколько вариантов решения данной проблемы:
— синхронная репликация( мастер будет ждать подтверждения insert’ов от standby);
— включать старый мастер (без ввода в кластер) и проверять, попали ли последние данные с мастера в кластер.
Определенный риск есть всегда, но в данной конфигурации мы имеем сценарий реализации HA. Придется с чем то мириться.
Проблем с железом не было.
Согласен, это справедливо для программирования, сколько потрачено ненужного времени в институте — самому можно научиться большему, востребованному и актуальному в n'ое количество раз. Преподаватели зачастую не могут внятно объяснить, а преподаваемые дисциплины уже неактуальны.
archive_command = 'cd .' — ни критичен.
wal_keep_segments = 3000 — да можно сократить, я привел это как пример. Необходимо настроить под себя.
— синхронная репликация( мастер будет ждать подтверждения insert’ов от standby);
— включать старый мастер (без ввода в кластер) и проверять, попали ли последние данные с мастера в кластер.
Определенный риск есть всегда, но в данной конфигурации мы имеем сценарий реализации HA. Придется с чем то мириться.
Проблем с железом не было.
Например так
В самом скрипте указываем userid получателей, и добавляем его в код скриптов.