Przełączanie awaryjne i replikacja PostgreSQL

Oceniam PostgreSQL 9.1 i mam kilka pytań związanych z przełączaniem awaryjnym i szczegółami replikacji.

Mam kilka scenariuszy testowych. Pierwszy z serwerem Master i kilkoma Slave. W przypadku awarii Mistrza chcę, aby jeden z Niewolników został Mistrzem. Po tym, jak Master powróci do normalnego stanu, powinien zsynchronizować się z innymi serwerami w klastrze (zastosować wszystkie zmiany wykonane, gdy był wyłączony) i odzyskać rolę Master lub zostać Slave.

Problemy, które widzę w PostgreSQL i bieżącym scenariuszu, są następujące.

1) Nie widzę wbudowanych narzędzi do wykrywania awarii serwera Master. Czytam, że pgpool może to obsłużyć i utworzyć plik wyzwalacza, czytam również, że ludzie używają pulsu Linuksa lub podobnych narzędzi do tego. OK, mogę wykryć przełączenie awaryjne i przypisać nowego Master w klastrze. Czy pozostali Niewolnicy zrozumieją, że jest nowy Mistrz i powinni go teraz wykonać?

2) Nie rozumiem procedury powrotu po awarii. Konfiguracje hosta Master i Slave są różne. Czy więc będę miał dwóch Mistrzów po awarii powrotu Mistrza? Jak serwery odzyskają synchronizację? Widziałem tylko ręczne rozwiązania, takie jak „przenieś folder danych na serwer i uruchom go ponownie”. Jakie jest zatem rozwiązanie lub najlepsza praktyka, a przynajmniej kluczowa zasada?

3) Jak poradzić sobie z awarią serwera po stronie klienta? Podczas tworzenia połączenia wyraźnie określam adres IP serwera. Czy powinienem opracować jakiś menedżer połączeń, który pozna moją strukturę Master-Slave, wysyłam żądania tylko do Master, a w przypadku utraty połączenia przełączy się na serwery zapasowe i tak dalej? Przeczytałem, że pgpool może być punktem wejścia dla aplikacji i zarządzać połączeniami we właściwy sposób. Czy pgpool jest tutaj jedynym rozwiązaniem? Czy dobrze radzi sobie z przełączaniem awaryjnym i zwrotnym?

4) Czy są jakieś rozwiązania (również komercyjne), więc mógłbym uniknąć ręcznego kopiowania danych, ponownej konfiguracji instancji PostgreSQL i innych rzeczy, które należy wykonać ręcznie? To taka konfiguracja klastra, kiedy wszyscy są zsynchronizowani, jasne jest, kto jest Mistrzem, a wszystko przełącza się automatycznie bez uwagi operatora?

Według tych wątków i artykułów

Replikacja strumieniowa i przełączanie awaryjne na PostgreSQL

Automatyzacja pracy awaryjnej w PostgreSQL 9.1

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

nie ma jednego w pełni automatycznego rozwiązania, aby rozwiązać te pytania. Czy mam rację?

Dzięki!

1. niewolnicy nie zrozumieją nowego mistrza. powinieneś to zrobić ręcznie.

2. tak, są one różne i powinieneś utworzyć nowe dla starego wzorca. jednak stary tryb gotowości będzie nadal działał jako wzorzec, ale powinieneś ustawić max_wal_senders w tym węźle. powinieneś także ustawić pg_hba.conf nowego mastera po przełączeniu awaryjnym. po przełączeniu awaryjnym (gdy węzły zmieniają role master-> slave slave-> master), należy przenieść nowe pliki wal do nowego katalogu danych folderów rezerwowych, który ustawiłeś w pliku recovery.conf. lub po prostu możesz użyć rsync.

3. być może możesz użyć pgbouncer. w ten sposób zmienisz adres serwera pgbouncer na nowy master.

4. EnterpriseDB ma kilka komercyjnych narzędzi. możesz je sprawdzić.

i wreszcie tak, masz rację. nie ma jednego w pełni automatycznego rozwiązania, aby rozwiązać te pytania.