Automatyzacja przełączania awaryjnego w PostgreSQL 9.1

Jak skonfigurować dwa identyczne serwery do automatycznego przełączania awaryjnego w PostgreSQL 9.1.

OS

Centos 5
PostgreSQL 9.1 skompilowany ze źródła
Konto użytkownika Postgres istnieje na obu komputerach i ma bezhasłowy klucz ssh do łączenia się z oboma komputerami.

Moja obecna konfiguracja:

Konfiguracja serwera głównego:

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

Serwer rezerwowy

Postgresql.conf i pg_hba.conf są identyczne z konfigurowanymi na serwerze głównym.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

Dzięki hzRoot rozumiem teraz, jak przełączyć serwer z trybu gotowości na tryb główny.

Korzystając z następujących poleceń, mogę zsynchronizować nowy moduł podrzędny z nowym modułem głównym, a następnie uzyskać kopię zapasową replikacji i uruchomić ją.

Na nowym komputerze głównym (10.0.66.2)

1. su - postgres
2. dotknij trigger.txt w / opt / pgsql91 / data /
3. recovery.conf zmienia się w recovery.done
4. psql -c "; SELECT pg_start_backup ('backup', true)";
5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
6. psql -c "; SELECT pg_stop_backup ()";

Na nowym slave (10.0.66.1)

1. utwórz plik recovery.conf: cp recovery.done to recovery.conf
2. vi recovery.conf zmień adres ip: primary_conninfo = 'host = 10.0.66.2'
3. rozpocznij postgresql

Więc moje pytania są teraz:

1. Czy to właściwy sposób na zmianę ról?
2. Czy ktoś zautomatyzował ten proces, jeśli tak, to co zrobiłeś?
3. Jeśli włączona jest replikacja synchroniczna, zauważyłem, że nowy serwer główny nie będzie dokonywał żadnych transakcji, ponieważ czeka na odpowiedź urządzenia podrzędnego. Nie ma jednak slave'a, ponieważ drugi serwer, stary master jest wyłączony. Czy to prawda, czy muszę tymczasowo wyłączyć replikację synchroniczną, gdy nowy moduł podrzędny jest wyłączony?

Sprawdź repmrg :

repmgr to zestaw narzędzi o otwartym kodzie źródłowym, który pomaga administratorom systemów i administratorom systemów zarządzać klastrem baz danych PostgreSQL.

Korzystając z funkcji Hot Standby wprowadzonej w PostgreSQL 9, repmgr znacznie upraszcza proces konfigurowania bazy danych i zarządzania nią przy wysokich wymaganiach dotyczących dostępności i skalowalności.

repmgr upraszcza administrację i codzienne zarządzanie, zwiększa produktywność i zmniejsza ogólne koszty klastra PostgreSQL poprzez:

• monitorowanie procesu replikacji; pozwalając DBA wydawać wysokie
• operacje dostępności, takie jak przełączenia i przełączenia awaryjne.

Robi dwie rzeczy:

1. repmgr: program komend, który wykonuje zadania w klastrze, a następnie kończy działanie
2. repmgrd: demon zarządzania i monitorowania, który obserwuje klaster i może automatyzować działania zdalne.

W przypadku automatycznego przełączania awaryjnego repmgrd rozwiązuje problem i nie jest SPOF w sieci, jak pgPool. Jednak nadal ważne jest monitorowanie wszystkich diamonów i przywracanie ich po awarii.

Wkrótce zostanie wydana wersja 2.0, w tym RPM.

w pliku Recovery.conf powinieneś dodać wiersz informujący postgres o przełączeniu awaryjnym z nadrzędnego na podrzędny. powinieneś dodać

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

podczas tworzenia tego pliku na podanej ścieżce. węzły się zmienią. (plik nie zawiera niczego, to tylko wyzwalacz)

można znaleźć dodatkowe informacje na temat replikacji strumieniowej

z drugiej strony może być możliwe, aby było automatycznie tworzone przy użyciu niektórych sztuczek, ale lepsze będzie użycie narzędzi do monitorowania i ręcznego przełączania awaryjnego.

Czy ktoś rozważał użycie do tego pgpool-II?

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

Konfiguruję replikację dla PostgreSQL. Wydaje się, że trudna część dzieje się, gdy stary mistrz wraca.

Z tego, co przeczytałem, pgpool wydaje się, że może zautomatyzować większość tego. Nie jestem jednak pewien, czy wykorzystuje funkcje replikacji już obecne w PostgreSQL 9.1.