Автоматизація відмови в PostgreSQL 9.1

Як встановити два однакових сервера для автоматичного відмови в 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. торкніться тригер.txt в / opt / pgsql91 / data /
3. recovery.conf стає recovery.done
4. psql -c "; SELECT pg_start_backup ('резервна копія', правда)";
5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
6. psql -c "; ВИБІР pg_stop_backup ()";

Про нового раба (10.0.66.1)

1. створити recovery.conf: cp recovery.done для recovery.conf
2. vi recovery.conf змінити ip-адресу: Primary_conninfo = 'host = 10.0.66.2'
3. почати postgresql

Отже, зараз мої запитання:

1. Це правильний спосіб перемикання ролей?
2. Хтось автоматизував цей процес, якщо так, що ви робили?
3. Якщо синхронна реплікація включена, я помітив, що новий головний сервер не здійснюватиме жодних транзакцій, оскільки він чекає, коли підлеглий відповість. Однак немає раба, тому що інший сервер, старий майстер, не працює. Це правильно чи мені потрібно тимчасово відключити синхронну реплікацію, поки новий підлеглий не працює?

Перевірте repmrg :

repmgr - це набір інструментів з відкритим кодом, що допомагає DBA та системним адміністраторам керувати кластером баз даних PostgreSQL.

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

repmgr спрощує адміністрування та щоденне управління, підвищує продуктивність і зменшує загальні витрати кластера PostgreSQL за рахунок:

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

Це робить дві речі:

1. repmgr: командна програма, яка виконує завдання на вашому кластері, а потім виходить
2. repmgrd: демон управління та моніторингу, який спостерігає за кластером і може автоматизувати віддалені дії.

Для автоматичного відмови, repmgrd виконує завдання і не є SPOF у вашій мережі, як-от pgPool. Однак все ще важливо стежити за всіма алмазами та повертати їх після відмови.

Вийде версія 2.0, включаючи RPM.

у вашому файлі recovery.conf слід додати рядок, який повідомляє postgres про відмову від master до slave. ви повинні додати

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

коли ви створюєте цей файл на заданому шляху. вузли зміняться. (файл не включає нічого, це лише тригер)

ви можете знайти додаткову інформацію про поточну реплікацію

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

Хтось думав використовувати для цього pgpool-II?

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

Я встановлюю реплікацію для PostgreSQL. Здається, хитра частина трапляється, коли старий господар повертається.

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