Automatyzacja przełączania awaryjnego w PostgreSQL 9.1

18

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?
postgresql failover Craig Efrein
źródło
1. tak poprawne 2. może być lepiej nie automatyzować tego procesu. 3. więc potrzebujesz co najmniej 2 slave i 1 master. ponieważ, jak powiedziałeś, synchronizacja. replikacja wymaga co najmniej 2 węzłów do synchronizacji w trybie push. jeśli jest tylko jeden węzeł główny, nie będziesz mógł zatwierdzić ..
sftsz
kroki 4, 5 i 6 nie są konieczne dla nowego wzorca, ponieważ, cóż, na początek replikujesz. Po drugie, co jeśli mistrz umrze i będzie offline - nie będziesz mógł się z nim połączyć. Kroki 4,5 i 6 są zwykle wykonywane na nowym węźle podrzędnym dołączającym do puli replikacji.
Eric
@Eric, kiedy się z tym bawiłem, kroki 4,5,6 są wymagane, aby przywrócić starego mistrza do stanu roboczego. Zmiana stanu gotowości na nowy podstawowy natychmiast powoduje nowy wpis WAL, więc teraz jest o 1 wpis przed starym mistrzem. Uruchomienie starego wzorca w trybie standy rzuciło na mnie błędy, więc musiałem wykonać kroki 4,5,6 na starym wzorzec, aby zsynchronizować go z nowym wzorzec (za pomocą pg_basebackup, który może przesyłać strumieniowo cały plik xlog z nowego wzorca - zastępuje kroki 4,5,6 w postgres> = 9.1). Czy mam rację, czy zrobiłem coś złego i to nie będzie konieczne?
Dalibor Filus

Odpowiedzi:

8

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.

Frank Heikens
źródło
Cześć Frank, dziękuję za odpowiedź. Nie słyszałem o repmrg i na pewno spróbuję.
Craig Efrein
Witaj ponownie Frank, Dzięki za repmgr, to było dokładnie to, czego szukałem. W końcu muszę to dzisiaj wypróbować.
Craig Efrein
4

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.

sftsz
źródło
Dziękuję za odpowiedź. Może to potrwać kilka dni, zanim będę mógł to przetestować, ale na pewno wrócę do ciebie.
Craig Efrein
Dam Ci +1 za odpowiedź pliku wyzwalacza, co pomogło mi znacznie usprawnić ten proces. To nie jest cała odpowiedź na to, jak w pełni zautomatyzować proces. Inną rzeczą, którą zauważyłem, jest to, że gdy master był wyłączony, transakcje nie zostały zakończone, ponieważ czekał na potwierdzenie przez master. Problem rozwiązano przy użyciu replikacji asynchronicznej
Craig Efrein
To całkiem niesamowite. Mam wiele uwag krytycznych dotyczących braku elastyczności w implementacji replikacji PostgreSQL, ale jest to świetny, prosty sposób obsługi przełączania awaryjnego.
Aaron Brown,
1
Jednak przejmuje on rolę nadrzędną, nawet gdy sam nadrzędny nadal działa (więc masz dwóch elementów nadrzędnych). Nie jest to zautomatyzowane przez sam postgres.
Dalibor Filus
0

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.

Paulo SantAnna
źródło
1
pgPool jest pojedynczym punktem awarii, tracisz wszystko, gdy spada.
Frank Heikens,
1
Dziękuję za Twoją odpowiedź. Próbowałem PGPool II z mieszanymi wynikami na CentOS i Debianie i ostatecznie się poddałem.
Craig Efrein
1
Dlaczego nie używać pgpool II z HAproxy? Z bicia serca i swobodnego słuchania ip?
mikiemorales
Dla celów historycznych pgpool-ii również obecnie nie działa w systemie Windows.
tommed