Автоматизация отработки отказа в PostgreSQL 9.1


18

Как настроить два одинаковых сервера для автоматического перехода на другой ресурс в PostgreSQL 9.1.

Операционные системы

Centos 5
PostgreSQL 9.1 скомпилирован из исходного кода
Учетная запись пользователя postgres существует на обеих машинах и имеет ssh-пароль без пароля для подключения к обеим машинам.

Моя текущая настройка:

Конфигурация главного сервера:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'  

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

Резервный сервер

postgresql.conf и pg_hba.conf идентичны тем, которые настроены на главном сервере.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

Благодаря hzRoot я теперь понимаю, как переключить сервер с резервного на главный.

Используя следующие команды, я могу синхронизировать нового ведомого с новым ведущим, а затем получить резервную копию репликации и запустить ее.

О новом мастере (10.0.66.2)

  1. су - постгрес
  2. коснитесь trigger.txt в / opt / pgsql91 / data /
  3. recovery.conf становится recovery.done
  4. psql -c "; SELECT pg_start_backup ('backup', true)";
  5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
  6. psql -c "; SELECT pg_stop_backup ()";

На новом рабе (10.0.66.1)

  1. создайте recovery.conf: cp recovery.done to recovery.conf
  2. vi recovery.conf изменить IP-адрес: primary_conninfo = 'host = 10.0.66.2'
  3. начать postgresql

Итак, мои вопросы сейчас:

  1. Это правильный способ поменяться ролями?
  2. Кто-нибудь автоматизировал этот процесс, если да, что вы делали?
  3. Если синхронная репликация включена, я заметил, что новый главный сервер не будет совершать никаких транзакций, потому что он ожидает ответа ведомого. Однако нет ведомого, потому что другой сервер, старый мастер не работает. Это правильно, или мне нужно временно отключить синхронную репликацию, когда новый ведомый не работает?

1. да, правильно 2. может быть, лучше не автоматизировать этот процесс. 3. так что вам нужно 2 подчиненных и 1 мастер по крайней мере. потому что, как вы сказали, синхронизировать. Репликация требует как минимум 2 узла для принудительной синхронизации. если там только один мастер-узел, вы не сможете зафиксировать ..
sftsz

шаги 4, 5 и 6 не нужны на новом мастере, потому что, ну, вы реплицируете для начала. Во-вторых, что, если мастер умер и был в автономном режиме - вы не сможете подключиться к нему. Шаги 4,5 и 6 обычно выполняются на новом подчиненном узле, присоединяющемся к пулу репликации.
Эрик

@ Эрик, поскольку я играл с этим, шаги 4,5,6 необходимы, чтобы вернуть старого мастера в рабочее состояние. Создание резервной новой первичной базы немедленно создает новую запись WAL, так что теперь она на 1 запись впереди старого мастера. Запуск старого мастера в режиме ожидания вызвал у меня ошибки, поэтому мне пришлось выполнить шаги 4,5,6 на старом мастере, чтобы синхронизировать его с новым мастером (используя pg_basebackup, который может передавать весь журнал xlog с нового мастера). - заменяет шаги 4,5,6 в postgres> = 9.1, я думаю). Я прав или я сделал что-то не так, и в этом нет необходимости?
Далибор Филус

Ответы:


8

Проверьте repmrg :

repmgr - это набор инструментов с открытым исходным кодом, который помогает администраторам баз данных и системным администраторам управлять кластером баз данных PostgreSQL.

Воспользовавшись возможностью горячего резервирования, представленной в PostgreSQL 9, repmgr значительно упрощает процесс настройки и управления базой данных с учетом требований высокой доступности и масштабируемости.

repmgr упрощает администрирование и ежедневное управление, повышает производительность и снижает общие затраты кластера PostgreSQL за счет:

  • мониторинг процесса репликации; позволяя администраторам баз данных выпускать
  • операции доступности, такие как переключение и переключение при сбое.

Это делает две вещи:

  1. repmgr: командная программа, которая выполняет задачи в вашем кластере и затем завершает работу
  2. repmgrd: демон управления и мониторинга, который наблюдает за кластером и может автоматизировать удаленные действия.

Для автоматического перехода на другой ресурс repmgrd делает свое дело и не является SPOF в вашей сети, как pgPool. Тем не менее, все еще важно следить за всеми демонами и восстанавливать их после сбоя.

Версия 2.0 скоро будет выпущена, включая RPM.


Привет Фрэнк, спасибо за ответ. Я не слышал о repmrg, и я обязательно попробую.
Крейг Эфрейн

Привет еще раз, Фрэнк, спасибо за repmgr, это было именно то, что я искал. Я наконец-то должен попробовать это сегодня.
Крейг Эфрейн

4

в вашем файле recovery.conf вы должны добавить строку, сообщающую postgres о переходе от главного к подчиненному. ты должен добавить

trigger_file = '/any/file/to/trigger'

когда вы создаете этот файл по заданному пути. узлы будут меняться. (файл не содержит ничего, это просто триггер)

вы можете найти дополнительную информацию о потоковой репликации

с другой стороны, возможно, будет возможно сделать его автоматически созданным с помощью некоторых хитростей, но лучше использовать инструменты мониторинга и ручное переключение при сбое.


Спасибо за ответ. Может пройти несколько дней, прежде чем я смогу это проверить, но я обязательно вернусь к вам.
Крейг Эфрейн

Я собираюсь дать вам +1 за ответ trigger_file, который помог мне значительно упростить процесс. Это не полный ответ, который заключается в том, как полностью автоматизировать процесс. Еще одна вещь, которую я заметил, это то, что пока мастер не работал, транзакции не завершались, потому что он ждал, пока мастер не подтвердит. Эта
проблема

Это довольно круто. У меня много критических замечаний по поводу отсутствия гибкости в реализации репликации PostgreSQL, но это отличный, простой способ обработки аварийного переключения.
Аарон Браун

1
Тем не менее, он берет на себя роль мастера, даже если сам мастер все еще работает (так что у вас есть два мастера). Это не автоматизировано самим Postgres.
Далибор Филус

0

Кто-нибудь рассматривал возможность использования pgpool-II для этого?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

Я настроил репликацию для PostgreSQL. Кажется, что сложная часть случается, когда старый мастер возвращается.

Из того, что я прочитал, pgpool может автоматизировать большую часть этого. Однако я не уверен, использует ли функции репликации, уже присутствующие в PostgreSQL 9.1.


1
pgPool - это единственная точка отказа, вы теряете все, когда происходит сбой.
Фрэнк Хайкенс

1
Спасибо за ваш ответ. Я попробовал PGPool II со смешанными результатами как на CentOS, так и на Debian, и в итоге сдался.
Крейг Эфрейн

1
Почему бы не использовать pgpool II с HAproxy? С биением сердца и плавающим ip прослушиванием?
mikiemorales

Просто для исторической справки, pgpool-ii также не работает в Windows.
Завтра
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.