[Из песочницы] OpenSCG’s HA failover solution “PGHA”. Решение Master-Slave для PostgreSQL 9.3

Ниже будет описан опыт настройки отказоустойчивой системы Master-Slave с использованием собственных ресурсов PostgresSQL — Asynchronous Replication + pgBouncer + PGHA — в формате вольного перевода с комментариями одного поста и руководства по установке.

pgHA

pgHA — программа написанная на Perl, код которой представлен в файле failoverd.pl, который и является основой инструмента. Использует в своей работе pgbouncer и собственную репликацию PostgresSQL; мониторит ведущую бд и в случае ее недоступности открывает вспомогательную бд на запись, останавливая репликацию. По крайней мере с версии 9.3 устанавливается вместе с PostgresSQL, скачать можно здесь. Процесс установки описан в файле README, который лежит в ./9.3/pgha/doc/.

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

Настройка

Данная система требует наличия трех машин: ведущего сервера (master), вспомогательного (slave) и узла масштабирования. Можно обойтись без последнего.

1. Настройка репликации

Про настройку нативной репликации уже написано в очень многих статьях, под этим предлогом я просто сошлюсь на некоторые:

2. Настройка pgBouncer

pgBouncer — легкий пулер, менеджер соединений для PostgreSQL. Здесь используется как входная точка доступа, которая перенаправляет запросы к главной бд или вспомогательной в зависимости от файла настроек. Устанавливается вместе с PostgresSQL 9.3.

1. Начать настройку нужно с создания пользователя bouncer и пароля к нему на сервере — узле масштабирования, или на любой другой машине которая будет следить за состоянием ведущего сервера.


2. Далее подготовить 2 файла pgbouncer.ini.orig и pgbouncer.ini.failover. Это файлы настройки pgbouncer и по сути отличаются лишь IP хостами бд: в файле .orig указан IP и порт ведущей бд, в .failover — вспомогательной. Примеры можно найти здесь.
   
   — не забудьте создать пустой log файл и указать путь к нему
   
   — еще нужно создать файл userlist.txt с пользователями под которыми будут делаться запросы через pgbouncer и не забыть указать путь к нему (поле auth_file), пример можно найти в ./9.3/share/doc/pgbouncer или здесь
   
   — выбрать пользователей из созданных, которые будут обладать правами админа в отношении к pgbouncer и указать их в поле admin_users
   
   — также нужно указать порт на котором будет находиться pgbouncer (listen_port) и далее, предварительно ознакомившись с другими заполненными полями и внеся где хочется изменения, можно обращаться к pgbouncer как к обычной бд… после запуска.


3. Создать файл pgbouncer.ini и скопировать в него содержимое файла pgbouncer.ini.orig. Это рабочий файл и в него далее будут копироваться файлы pgbouncer.ini.orig или pgbouncer.ini.failover в зависимости от ситуации. Создать пустой файл pgbouncer.ini_old, он будет использоваться pgha.


4. Запустить pgbouncer от лица пользователя bouncer:
   
   pgbouncer -d /путь/pgbouncer.ini
   

3. Настройка pgHA

1. pgHA использует некоторые Perl модули, которые требуется предварительно установить. Перед этим нужно установить CPAN:
   

   
   yum install perl-CPAN 
   perl -MCPAN -e 'install Module::Build::Compat'
   perl -MCPAN -e 'install Config::IniFiles'
   perl -MCPAN -e 'install DBI'
   perl -MCPAN -e 'install DBD::Pg'
   perl -MCPAN -e 'install Log::Log4perl'
   perl -MCPAN -e 'install Proc::Daemon'
   perl -MCPAN -e 'install Net::Ping'
   perl -MCPAN -e 'install Nagios::Plugin'
   

   
   
   
   При этом может возникать безвредная ошибка: yaml' not installed will not store persistent state. Если раздражает, можно сделать:
   

   
   cpan
   install Bundle::CPAN
   reload cpan
   exit 
   

   
   
   


2. Далее следует подготовить файл настроек для pgHA, примеры которого можно найти в папке ./9.3/pgHA/cfg/ или здесь: файлы example.conf и scottmVm.conf, лучше ориентироваться на второй:
   
   — pidFile может лежать в любом месте, нужно убедиться в доступности выбранного пути.
   
   — logConfig находится в ./9.3/pgHA/cfg/log4perl.conf и содержит настройки логирования
   
   — для triggerFile нужно указать файл указанный в recovery.conf
   
   — раздел [failover] пока лучше удалить, чуть ниже будет упомянуто и о нем
   
   — в разделе [app01] содержатся настройки pgbouncer, в том числе в конце файла описаны команды которые в случае отказа ведущей базы удаляют все соединения к ней и затем перезапускают pgbouncer для работы с новой главной бд:
   

   
   # Which databases should be part of failover
   fence_lock_dbs=postgres
   # pgBouncer command to pause / fence the db's
   fence_lock_command=kill
   # pgBouncer command to reload the config file
   fence_move_command=reload
   # pgBouncer command to unlock the db's
   fence_unlock_command=resume
   dbcheck="select 1"
   

   
   
   
   — в разделе [app01] в поле pgbouncer_db_user должен стоять один из admin_users указанных в pgbouncer.ini
   
   — следует ознакомиться и с остальными параметрами


3. Затем создать пустой log файл pgHA.log в папке /opt/pgHA/log/. Именно этот путь использует по умолчанию pgHA.


4. На ведущем сервере создать таблицу описанную в файле ./9.3/pgha/cfg/status_table.sql, или здесь в бд указанной в поле dbname в разделе [master].


5. Сгенерировать ssh ключ пользователя от имени которого будет запускаться pgHA и переслать его пользователю bouncer:
   
   — ssh-keygen -t rsa (создать пустой пароль)
   
   — скопировать содержимое ~/.ssh/id_rsa.pub
   
   — на машине с пользователем bouncer от его лица выполнить команды:
   
   mkdir ~/.ssh

chmod 0700 .ssh

vi authorized_keys (вставить ранее скопированное содержимое id_rsa.pub, закрыть с сохранением)
   
   chmod 0600 .ssh/authorized_keys


6. Запустить pgHA.
   
   ./failoverd.pl -c /путь/файлНастроекPgHA.conf --auto
   
   Файл failoverd.pl лежит в папке ./9.3/pgHA/bin.


7. Если пункт 6 прошел без ошибок, остановить pgHA
   
   ./failoverd.pl -c /путь/файлНастроекPgHA.conf --stop
   
   В данном состоянии pgHA автоматического failover не случится. Нужно открыть файл failoverd.pl, закомментировать строчку 443 и откомментировать 442 согласно коду представленному здесь. Должно получиться:
   

   
   # Start the failoverd monitoring process
   elsif ( $startWorker )
   {
       print "\n\tInitializing... \n";
        .   .   .  
       # Once we have verified that the system is online, we need
       # to set the failover 'spring'.  
       $logger->info("==Startup==: Arming Failover mechanism");
       print "\t === Arming Failover mechanism === \n";
       if ( SetSpring(%Config,$logger) != 1 )
   #    if ( 0 )
       {
           $logger->info("Cannot set failover configuration, exiting...");
           print "Cannot set failover configuration, exiting...\n";
           exit(1);
       }
        .   .   . 
   

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


8. Запустить pgHA. Тестить.

P.S.

В разделе [failover] указываются команды, которые исполняются во время failover. Таким образом можно, например, не менять код в failoverd.pl, а создать скрипт — который меняет файл настроек pgbouncer и перезагружает его — и указать на него.

Данное решение не уменьшает скорость работы программ, использующих базу данных, и при хорошей настройке pgbouncer может ее увеличить. Плюсом также считаю открытость кода pgHA — его можно дополнять, чтобы научить, например, попыткам перезагрузить ведущую базу перед failover, возобновлять репликацию, менять шрифт в терминале и т.д.

Решение для postgres 8.4 представлено в вышеупомянутом блоге.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.