Перелом та реплікація PostgreSQL

Я оцінюю PostgreSQL 9.1 і маю кілька питань, пов’язаних із деталями відмови та реплікації.

У мене мало тестових сценаріїв. Перший з головним сервером та кількома рабами. У випадку, коли Майстер зірветься, я хочу, щоб один з Рабів став Господарем. Після того, як Master повернеться до нормального стану, він повинен синхронізуватися з іншими серверами в кластері (застосувати всі зміни, зроблені, поки він не був) і повернути назад роль Master або стати рабом.

Проблеми, які я бачу з PostgreSQL та поточним сценарієм, наступні.

1) Я не бачу вбудованих інструментів для виявлення відключення головного сервера. Я читав, що pgpool може це впоратися і створити тригер-файл, також прочитав, що люди використовують для цього серцебиття Linux або подібні інструменти. Гаразд, я можу виявити відмову та призначити нового майстра в кластері. Чи зрозуміють інші Раби, що є новий Майстер, і вони повинні створити резервну копію зараз?

2) Я не розумію процедури відмови. Конфігурації головного та підлеглого хостів різні. Тож у мене будуть два майстри після відмови відмовки Майстра? Як сервери повернуться синхронізовано? Я бачив лише рішення вручну, такі як "перенести папку даних на сервер і перезапустити її". То яке рішення чи найкраща практика чи принаймні ключовий принцип тут?

3) Як мені впоратися з відключенням сервера на стороні клієнта? Коли я створюю з'єднання, я чітко вказую IP-адресу сервера. Чи повинен я розробити якийсь ConnectionManager, який буде знати мою структуру Master-Slave, надсилати запити лише Master та в разі втрати з'єднання перейде на резервні сервери тощо? Я читав, що pgpool може бути точкою входу для програм і керувати з'єднаннями правильно. Є pgpool єдиним рішенням тут? Чи добре справляється з відмовою та відмовою?

4) Чи є якісь рішення (комерційні також), щоб я міг уникати копіювання даних вручну, переналаштування екземплярів PostgreSQL та інших речей, які слід робити руками? Отже, така конфігурація кластера, коли всі синхронізуються, зрозуміло, хто Master, і все автоматично перемикається без уваги оператора?

Відповідно до цих тем і статей

Потокове реплікація та відмова на PostgreSQL

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

http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html

не існує єдиного повністю автоматичного рішення для вирішення цих питань. Я правий?

Спасибі!

1. раби не зрозуміють нового господаря. вам слід це зробити вручну.

2. так, вони різні, і ви повинні створити нові для старого майстра. Хоча старий режим очікування буде продовжувати працювати майстром, але вам слід встановити max_wal_senders на цьому вузлі. Ви також повинні встановити pg_hba.conf нового майстра після відмови. після відмови (коли вузли змінюють ролі master-> slave-slave-> master), ви повинні перенести нові файли wal у новий каталог даних папок очікування, який ви встановили у файл recovery.conf. або просто ви можете використовувати rsync.

3. Ви можете використовувати pgbouncer. таким чином ви просто зміните адресу сервера pgbouncer на новий головний.

4. EnterpriseDB має деякі комерційні інструменти. Ви можете їх перевірити.

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