Ciągłość biznesowa baz danych
Ciągłość biznesowa baz danych oznacza, że bazy danych muszą działać nieprzerwanie nawet podczas awarii. Konieczne jest zapewnienie, że produkcyjne bazy danych są dostępne dla aplikacji przez cały czas, nawet podczas awarii, w przeciwnym razie może to być kosztowna transakcja. Administratorzy baz danych, architekci musieliby zapewnić, że środowiska baz danych są w stanie wytrzymać awarie i są zgodne z umową SLA odzyskiwania danych po awarii. Aby zapewnić, że awarie nie wpłyną na dostępność bazy danych, bazy danych muszą być skonfigurowane pod kątem ciągłości biznesowej.
Konfiguracja baz danych pod kątem ciągłości biznesowej wymaga wielu prac związanych z architekturą, planowaniem, projektowaniem i testowaniem. Wiele czynników, takich jak centra danych i ich terytoria geograficzne, w tym projektowanie infrastruktury, jest branych pod uwagę przy projektowaniu i wdrażaniu skutecznej strategii odzyskiwania po awarii dla baz danych. To wyjaśnia fakt, że „Ciągłość działania =unikanie przestojów podczas katastrof ”.
Aby zapewnić przetrwanie produkcyjnych baz danych w przypadku awarii, należy skonfigurować witrynę odzyskiwania po awarii (DR). Lokalizacje produkcyjne i DR muszą być częścią dwóch odległych geograficznie centrów danych. Oznacza to, że rezerwowa baza danych musi być skonfigurowana w lokacji DR dla każdej produkcyjnej bazy danych, tak aby zmiany danych zachodzące w produkcyjnej bazie danych były natychmiast synchronizowane z rezerwową bazą danych za pośrednictwem dzienników transakcji. Można to osiągnąć dzięki funkcji „replikacji strumieniowej” w PostgreSQL.
Co musi się stać, jeśli katastrofa uderzy w produkcyjną (lub podstawową) bazę danych?
Gdy produkcyjna (podstawowa) baza danych ulegnie awarii lub przestanie odpowiadać, rezerwowa baza danych musi zostać podniesiona do podstawowej, a aplikacje muszą być skierowane do nowo promowanej rezerwowej (nowej podstawowej) bazy danych, a wszystko to musi nastąpić automatycznie w ramach wyznaczonej umowy SLA dotyczącej wyłączenia. Ten proces jest określany jako przełączanie awaryjne.
Konfigurowanie PostgreSQL pod kątem wysokiej dostępności
Jak wspomniano powyżej, aby upewnić się, że PostgreSQL jest zgodny z odtwarzaniem po awarii, należy go najpierw skonfigurować za pomocą replikacji strumieniowej (baza główna + rezerwowa baza danych) oraz z automatycznym promocją stanu gotowości/przełączaniem awaryjnym. Przyjrzyjmy się, jak najpierw skonfigurować replikację strumieniową, a następnie proces „przełączania awaryjnego”.
Konfigurowanie rezerwowej bazy danych (replikacja strumieniowa)
Replikacja strumieniowa to wbudowana funkcja PostgreSQL, która zapewnia replikację danych z podstawowej do rezerwowej bazy danych za pośrednictwem rekordów WAL i obsługuje zarówno metody replikacji asynchronicznej, jak i synchronicznej. Ten sposób replikacji jest dość niezawodny i odpowiedni dla środowisk wymagających wysokiej wydajności replikacji w czasie rzeczywistym.
Konfiguracja trybu gotowości do przesyłania strumieniowego jest dość prosta. Pierwszym krokiem jest upewnienie się, że podstawowe konfiguracje bazy danych są następujące:
Obowiązkowe konfiguracje podstawowej bazy danych
Upewnij się, że następujące parametry są skonfigurowane w postgresql.conf w podstawowej bazie danych. Wykonanie poniższych zmian wymagałoby ponownego uruchomienia bazy danych.
wal_level=logicalParametr wal_level zapewnia, że informacje wymagane do replikacji są zapisywane w plikach WAL.
max_wal_senders=1 (or any number more than 0)Rekordy WAL są wysyłane przez proces wal sender z podstawowej bazy danych do rezerwowej bazy danych. Tak więc powyższy parametr musi być skonfigurowany na minimum 1. Więcej niż wartość 1 jest wymagana, gdy wymaganych jest wiele nadawców wal.
Włącz archiwizację WAL
Nie ma twardej zależności od archiwizacji WAL w przypadku replikacji strumieniowej. Jednak zdecydowanie zaleca się skonfigurowanie archiwizacji WAL, ponieważ jeśli stan gotowości pozostaje w tyle i jeśli wymagane pliki WAL zostaną usunięte z katalogu pg_xlog (lub pg_wal), wówczas pliki archiwum będą wymagane, aby zsynchronizować stan gotowości z podstawowym jeśli nie, tryb gotowości musi zostać odbudowany od zera.
archive_mode=on
archive_command=<archive location>Podstawowa baza danych musi być skonfigurowana do akceptowania połączeń w trybie gotowości.
Poniższa konfiguracja musi znajdować się w pg_hba.conf
host replication postgres <standby-database-host-ip>/32 trustTeraz wykonaj kopię zapasową podstawowej bazy danych i przywróć ją w witrynie DR. Po zakończeniu przywracania utwórz plik recovery.conf w katalogu danych z poniższą zawartością:
standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’Teraz uruchom rezerwową bazę danych. Replikacja strumieniowa musi być włączona. Poniższy komunikat w pliku dziennika postgresql rezerwowej bazy danych potwierdza, że replikacja strumieniowa działa pomyślnie:
2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG: started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG: redo starts at 127/CD380170To oznacza, że istnieje w pełni funkcjonalna replikacja strumieniowa. Następny krok do instalacji/konfiguracji repmgr. Zanim to nastąpi, pozwól nam zrozumieć proces przełączania awaryjnego.
Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokumentCo to jest przełączanie awaryjne?
Przełączanie awaryjne występuje, gdy podstawowa baza danych staje się całkowicie niedostępna z powodu awarii. Podczas procesu przełączania awaryjnego, rezerwowa baza danych zostanie awansowana na nową podstawową bazę danych, dzięki czemu aplikacje będą mogły kontynuować operacje biznesowe.
Automatyczne przełączanie awaryjne
Cały proces przełączania awaryjnego musi odbywać się automatycznie, aby zapewnić efektywną ciągłość biznesową, a to można osiągnąć tylko za pomocą niektórych narzędzi oprogramowania pośredniczącego. Cały pomysł polega na unikaniu ręcznej interwencji administratorów baz danych, programistów.
Jednym z takich narzędzi, które pomaga wykonać automatyczne przełączanie awaryjne, jest „repmgr”.
Przyjrzyjmy się repmgr i jego możliwościom.
Przedstawiciel
Repmgr to narzędzie typu open source opracowane przez 2nd Quadrant. To narzędzie pomaga wykonywać różne czynności administracyjne bazy danych, takie jak budowanie i monitorowanie replikacji PostgreSQL, w tym wykonywanie automatycznych czynności przełączania awaryjnego w przypadku awarii, a także pomaga wykonywać operacje przełączania.
Repmgr jest łatwym w instalacji narzędziem, a konfiguracje również nie są skomplikowane. Przyjrzyjmy się najpierw instalacji:
Instalowanie repmgr
Pobierz narzędzie stąd.
Rozpakuj archiwum tar i wykonaj instalację, jak pokazano poniżej:
Zainstalowałem repmgr-4.2.0 na hoście CentOS 7 i zainstalowałem repmgr przeciwko PostgreSQL-11.1. Przed instalacją upewnij się, że katalog bin PostgreSQL jest częścią $PATH, a katalog lib PostgreSQL jest częścią $LD_LIBRARY_PATH. Aby zrozumieć, że repmgr jest zainstalowany przeciwko PostgreSQL-11.1, wyświetlam poniżej wynik „make install”:
[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755 repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'Konfigurowanie repmgr dla automatycznego przełączania awaryjnego
Zanim przyjrzymy się konfigurowaniu „repmgr”, bazy danych muszą być skonfigurowane z replikacją strumieniową, którą widzieliśmy wcześniej. Na początek obie bazy danych (podstawowa i rezerwowa) muszą być skonfigurowane z następującym parametrem w postgresql.conf:
Primary
[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr' # (change requires restart)
Standby
[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr' # (change requires restart)
Powyższy parametr ma na celu włączenie demona „repmgrd”, który stale działa w tle i monitoruje replikację strumieniową. Bez tego parametru nie jest możliwe automatyczne przełączanie awaryjne. Zmiana tego parametru wymagałaby ponownego uruchomienia bazy danych.
Następnie utwórz plik konfiguracyjny repmgr (powiedzmy o nazwie repmgr.conf) dla obu baz danych. Podstawowa baza danych musi zawierać plik konfiguracyjny o następującej zawartości:
node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'Umieść plik w katalogu danych, w tym przypadku jest to „/data/pgdata11”.
Plik konfiguracyjny rezerwowej bazy danych musi mieć następującą zawartość:
node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'
failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'
monitoring_history=yes
monitor_interval_secs=5
log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG
promote_check_timeout=5
promote_check_interval=1
master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10
Obie bazy danych muszą być zarejestrowane w repmgr.
Zarejestruj podstawową bazę danych
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registeredZarejestruj rezerwową bazę danych
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registeredUruchom poniższe polecenie, aby upewnić się, że rejestrowanie repmgr działa.
[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"
Jeśli możesz zaobserwować, skonfigurowałem log_level do DEBUG, aby generować szczegółowe rejestrowanie w pliku repmgr.conf w trybie gotowości. Sprawdź dzienniki pod kątem stanu replikacji.
Sprawdź, czy replikacja działa zgodnie z oczekiwaniami za pomocą repmgr:
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
1 | node1 | primary | * running | | default | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
2 | node2 | standby | running | node1 | default | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2Powyższy komunikat potwierdza, że replikacja działa prawidłowo.
Teraz, jeśli zamknę podstawową bazę danych, demon repmgrd powinien wykryć awarię podstawowej bazy danych i powinien promować rezerwową bazę danych. Zobaczmy, czy tak się stanie — podstawowa baza danych jest zatrzymana:
[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stoppedRezerwowa baza danych musi być promowana automatycznie. Dzienniki repmgr pokażą to samo:
fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name FROM repmgr.nodes n WHERE n.upstream_node_id = 1 AND n.node_id != 2 AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name FROM repmgr.nodes n WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
"repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primaryPowyższe dokładnie oznacza, że repmgr nie był w stanie połączyć się z podstawową bazą danych i po nieudanych 5 próbach, rezerwowy jest promowany do nowej podstawowej bazy danych. Poniżej znajdują się dzienniki promowanej rezerwowej (nowej podstawowej) bazy danych:
2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not connect to server: Connection refused
Is the server running on host "xxx.xxx.xx.xx" and accepting
TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG: received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG: redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG: last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG: selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG: archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG: checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG: database system is ready to accept connectionsWspomniałem tylko o ważnych parametrach w pliku konfiguracyjnym repmgr. Istnieje wiele innych parametrów, które można modyfikować w celu spełnienia różnych wymagań. Inne ważne parametry to parametry replication_lag_*, jak pokazano poniżej:
#replication_lag_warning=300 # repmgr node check --replication-lag
#replication_lag_critical=600 #Repmgr sprawdzi progi powyższych parametrów przed promocją stanu gotowości. Jeśli opóźnienie replikacji jest krytyczne, promocja nie zostanie rozpoczęta. Co jest naprawdę dobre, ponieważ jeśli tryb gotowości zostanie promowany, gdy wystąpi opóźnienie, które może spowodować utratę danych.
Aplikacje muszą zapewnić pomyślne ponowne nawiązanie połączenia z nowo promowanym trybem gotowości w oczekiwanym czasie. Systemy równoważenia obciążenia miałyby możliwość przekierowania połączeń aplikacji, gdy podstawowa baza danych przestanie odpowiadać. Inną alternatywą byłoby użycie narzędzi oprogramowania pośredniego, takich jak PgPool-II, aby zapewnić pomyślne przekierowanie wszystkich połączeń.
Aby zapewnić pomyślne wdrożenie architektury wysokiej dostępności w środowisku produkcyjnym, należy przeprowadzić dokładne, kompleksowe testy całego procesu. Z mojego doświadczenia wynika, że nazywamy to ćwiczenie DRILL. Oznacza to, że co około 6 miesięcy wykonywana byłaby operacja przełączania, aby upewnić się, że stan gotowości jest pomyślnie promowany, a połączenia aplikacji pomyślnie ponownie łączą się z promowanym stanem gotowości. Istniejąca podstawa stanie się nowym rezerwowym. Gdy operacja przełączania się powiedzie, metryki są usuwane, aby sprawdzić, czy spełnione są umowy SLA.
Co to jest przełączenie?
Jak wyjaśniono powyżej, Przełączanie jest zaplanowanym działaniem, w którym następuje zamiana ról podstawowej i rezerwowej bazy danych. Oznacza to, że tryb gotowości stanie się podstawowym, a podstawowy stanie się gotowością. Za pomocą repmgr można to osiągnąć. Poniżej znajduje się, co robi repmgr po wydaniu polecenia przełączania.
$ repmgr -f /etc/repmgr.conf standby switchover
NOTICE: executing switchover on node "node2" (ID: 2)
INFO: searching for primary node
INFO: checking if node 1 is primary
INFO: current primary node is 1
INFO: SSH connection to host "node1" succeeded
INFO: archive mode is "off"
INFO: replication lag on this standby is 0 seconds
NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
NOTICE: stopping current primary node "node1" (ID: 1)
NOTICE: issuing CHECKPOINT
DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
INFO: checking primary status; 1 of 6 attempts
NOTICE: current primary has been cleanly shut down at location 0/0501460
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
server promoting
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary
INFO: setting node 1's primary to node 2
NOTICE: starting server using "pg_ctl -D '/data/pgdata11' restart"
NOTICE: NODE REJOIN successful
DETAIL: node 1 is now attached to node 2
NOTICE: switchover was successful
DETAIL: node "node2" is now primary
NOTICE: STANDBY SWITCHOVER is completeCo jeszcze może zrobić repmgr?
- Repmgr może pomóc w budowaniu baz danych od podstaw
- Wiele rezerwowych baz danych można zbudować z jednego uruchomionego mastera
- Można zbudować kaskadowe rezerwy, co moim zdaniem jest bardziej korzystne niż konfigurowanie wielu rezerw w jednej głównej bazie danych
Co się stanie, jeśli znikną zarówno tryb podstawowy, jak i tryb gotowości?
Cóż, jest to sytuacja, w której biznes myśli o posiadaniu wielu instancji rezerwowych. Jeśli wszystkie znikną, jedynym wyjściem jest przywrócenie bazy danych z kopii zapasowych. To jest powód, dla którego dobra strategia tworzenia kopii zapasowych jest niezbędna. Kopie zapasowe muszą być testowo przywracane i regularnie sprawdzane, aby zapewnić niezawodność kopii zapasowych. Projekt infrastruktury kopii zapasowych musi być taki, aby przywracanie i odzyskiwanie kopii zapasowych nie trwało długo. Proces przywracania i odzyskiwania kopii zapasowych musi zostać zakończony w ramach wyznaczonej umowy SLA. Umowy SLA dla kopii zapasowych są projektowane pod kątem RTO (Recovery Time Objective) i RPO (Recovery Point Objective). Oznacza to, że RTO:czas potrzebny na przywrócenie i odzyskanie kopii zapasowej musi mieścić się w ramach umowy SLA i RPO:do momentu, w którym wykonano odzyskiwanie, musi być akceptowalny, innymi słowy jest to tolerancja na utratę danych i ogólnie firmy mówią o zerowej utracie danych tolerancja.
Wniosek
- Ciągłość biznesowa PostgreSQL jest ważnym wymogiem dla środowisk baz danych o znaczeniu krytycznym. Osiągnięcie tego wymaga dużo planowania i kosztów.
- Zasoby i infrastruktura muszą być optymalnie wykorzystywane, aby zapewnić skuteczną strategię odzyskiwania po awarii.
- Mogą być wyzwania z punktu widzenia kosztów, którymi należy się zająć
- Jeśli budżet na to pozwala, upewnij się, że istnieje wiele lokalizacji DR do przełączenia awaryjnego
- W przypadku, gdy kopie zapasowe mają zostać przywrócone, upewnij się, że istnieje dobra strategia tworzenia kopii zapasowych.
