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.  
  3. Далі підготувати 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 як до звичайної бд… після запуску.
     
     
  4.  
  5. Створити файл pgbouncer.ini і скопіювати в нього вміст файлу pgbouncer.ini.orig. Це робочий файл і в нього далі будуть копіюватися файли pgbouncer.ini.orig або pgbouncer.ini.failover залежно від ситуації. Створити порожній файл pgbouncer.ini_old, він буде використовуватися pgha.
     
     
  6.  
  7. Запустити pgbouncer від особи користувача bouncer:
     
    pgbouncer -d /путь/pgbouncer.ini

     
  8.  
 
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.  
  3. Далі слід підготувати файл настройок для 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
     - Слід ознайомитися і з іншими параметрами
     
     
  4.  
  5. Потім створити порожній log файл pgHA.log в папці / opt / pgHA / log /. Саме цей шлях використовує за замовчуванням pgHA.
     
     
  6.  
  7. На провідному сервері створити таблицю описану у файлі ./9.3/pgha/cfg/status_table.sql, або тут в бд зазначеної в поле dbname в розділі [master].
     
     
  8.  
  9. Згенерувати 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

     
     
  10.  
  11. Запустити pgHA.
      
    ./failoverd.pl -c /путь/файлНастроекPgHA.conf --auto

    Файл failoverd.pl лежить в папці ./9.3/pgHA/bin.
     
     
  12.  
  13. Якщо пункт 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 з налаштуваннями для роботи з новою головною бд і завершить свою роботу. Повертати систему в початковий стан потрібно в ручну.
     
     
  14.  
  15. Запустити pgHA. Тестить.
  16.  
 
P.S.
У розділі [failover] вказуються команди, які виконуються під час failover. Таким чином можна, наприклад, не змінювати код в failoverd.pl, а створити скрипт — який змінює файл настройок pgbouncer і перезавантажує його — і вказати на нього.
 
Дане рішення не зменшує швидкість роботи програм, що використовують базу даних, і при гарній налаштування pgbouncer може її збільшити. Плюсом також вважаю відкритість коду pgHA — його можна доповнювати, щоб навчити, наприклад, спробам перезавантажити провідну базу перед failover, відновлювати реплікацію, міняти шрифт в терміналі і т.д.
 
Рішення для postgres 8.4 представлено у вищезгаданому блозі .

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.