PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Konfigurieren von PostgreSQL für Business Continuity

Geschäftskontinuität für Datenbanken

Business Continuity für Datenbanken bedeutet, dass Datenbanken auch während der Katastrophen kontinuierlich betriebsbereit sein müssen. Es muss unbedingt sichergestellt werden, dass die Produktionsdatenbanken für die Anwendungen auch während der Katastrophen jederzeit verfügbar sind, da dies sonst zu einer teuren Angelegenheit werden kann. DBAs und Architekten müssten sicherstellen, dass Datenbankumgebungen Katastrophen standhalten und SLA-konform für die Notfallwiederherstellung sind. Um sicherzustellen, dass Katastrophen die Datenbankverfügbarkeit nicht beeinträchtigen, müssen Datenbanken für Geschäftskontinuität konfiguriert werden.

Die Konfiguration von Datenbanken für Business Continuity erfordert viel Architektur, Planung, Design und Tests. Viele Faktoren wie Rechenzentren und ihre geografischen Gebiete, einschließlich des Infrastrukturdesigns, müssen berücksichtigt werden, wenn es darum geht, eine effektive Notfallwiederherstellungsstrategie für Datenbanken zu entwerfen und zu implementieren. Das erklärt die Tatsache, dass „Business Continuity =Ausfälle bei Katastrophen vermeiden “.

Um sicherzustellen, dass Produktionsdatenbanken einen Notfall überstehen, muss ein Disaster Recovery (DR)-Standort konfiguriert werden. Produktions- und DR-Standorte müssen Teil zweier geografisch entfernter Rechenzentren sein. Das bedeutet, dass am DR-Standort für jede Produktionsdatenbank eine Standby-Datenbank konfiguriert werden muss, sodass die in der Produktionsdatenbank auftretenden Datenänderungen sofort über Transaktionsprotokolle mit der Standby-Datenbank synchronisiert werden. Dies kann durch die „Streaming Replication“-Funktion in PostgreSQL erreicht werden.

Was muss passieren, wenn eine Katastrophe die Produktions- (oder primäre) Datenbank trifft?

Wenn die (primäre) Produktionsdatenbank abstürzt oder nicht mehr reagiert, muss die Standby-Datenbank zur primären heraufgestuft werden und die Anwendungen müssen auf die neu heraufgestufte (neue primäre) Standby-Datenbank verweisen, und all dies muss automatisch innerhalb der festgelegten Ausfall-SLA erfolgen. Dieser Vorgang wird als Failover bezeichnet.

Konfigurieren von PostgreSQL für Hochverfügbarkeit

Um sicherzustellen, dass PostgreSQL Disaster-Recovery-kompatibel ist, muss es, wie oben erwähnt, zunächst mit Streaming-Replikation (Master- und Standby-Datenbank) und mit automatischen Standby-Hochstufungs-/Failover-Funktionen konfiguriert werden. Sehen wir uns zuerst an, wie die Streaming-Replikation konfiguriert wird, und dann den „Failover“-Prozess.

Standby-Datenbank konfigurieren (Streaming-Replikation)

Die Streaming-Replikation ist die integrierte Funktion von PostgreSQL, die sicherstellt, dass Daten über WAL-Einträge von der primären in die Standby-Datenbank repliziert werden, und unterstützt sowohl asynchrone als auch synchrone Replikationsmethoden. Diese Art der Replikation ist sehr zuverlässig und für Umgebungen geeignet, die eine Replikation in Echtzeit und mit hoher Leistung erfordern.

Das Konfigurieren des Streaming-Standby ist ziemlich einfach. Der erste Schritt besteht darin, sicherzustellen, dass die primären Datenbankkonfigurationen wie folgt sind:

Obligatorische Konfigurationen der primären Datenbank

Stellen Sie sicher, dass die folgenden Parameter in postgresql.conf in der primären Datenbank konfiguriert sind. Die Durchführung der folgenden Änderungen würde einen Neustart der Datenbank erfordern.

wal_level=logical

Der Parameter wal_level stellt sicher, dass die für die Replikation erforderlichen Informationen in die WAL-Dateien geschrieben werden.

max_wal_senders=1 (or any number more than 0)

WAL-Datensätze werden durch den Wal-Sender-Prozess von der primären Datenbank an die Standby-Datenbank gesendet. Daher muss der obige Parameter auf mindestens 1 konfiguriert werden. Mehr als ein Wert von 1 ist erforderlich, wenn mehrere Wal-Sender erforderlich sind.

WAL-Archivierung aktivieren

Es gibt keine feste Abhängigkeit von der WAL-Archivierung für die Streaming-Replikation. Es wird jedoch dringend empfohlen, die WAL-Archivierung zu konfigurieren, da, wenn die Standby-Datei hinterherhinkt und die erforderlichen WAL-Dateien aus dem Verzeichnis pg_xlog (oder pg_wal) entfernt werden, Archivdateien erforderlich sind, um die Standby-Datei mit der primären zu synchronisieren Wenn nicht, muss der Standby-Modus von Grund auf neu erstellt werden.

archive_mode=on
archive_command=<archive location>

Die primäre Datenbank muss so konfiguriert werden, dass sie Verbindungen vom Standby akzeptiert.

Die folgende Konfiguration muss in pg_hba.conf

vorhanden sein 
host    replication     postgres        <standby-database-host-ip>/32            trust

Erstellen Sie nun eine Sicherungskopie der primären Datenbank und stellen Sie diese auf der DR-Site wieder her. Erstellen Sie nach Abschluss der Wiederherstellung die Datei recovery.conf im Datenverzeichnis mit dem folgenden Inhalt:

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’

Starten Sie nun die Standby-Datenbank. Die Streaming-Replikation muss aktiviert sein. Die folgende Meldung in der Postgresql-Protokolldatei der Standby-Datenbank bestätigt, dass die Streaming-Replikation erfolgreich funktioniert:

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/CD380170

Daraus folgt, dass eine voll funktionsfähige Streaming-Replikation vorhanden ist. Nächster Schritt zum Installieren/Konfigurieren von repmgr. Lassen Sie uns vorher den Failover-Prozess verstehen.

Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter

Was ist Failover?

Ein Failover tritt auf, wenn die primäre Datenbank aufgrund eines Notfalls vollständig nicht verfügbar ist. Während des Failover-Prozesses wird die Standby-Datenbank zu einer neuen primären Datenbank heraufgestuft, damit Anwendungen den Geschäftsbetrieb fortsetzen können.

Automatisches Failover

Der gesamte Failover-Prozess muss automatisch erfolgen, um eine effektive Geschäftskontinuität zu gewährleisten, und dies kann nur durch einige Middleware-Tools erreicht werden. Die ganze Idee ist, ein manuelles Eingreifen von DBAs, Entwicklern zu vermeiden.

Ein solches Tool, das beim automatischen Failover hilft, ist „repmgr“.

Werfen wir einen Blick auf repmgr und seine Fähigkeiten.

Repmgr

Repmgr ist ein Open-Source-Tool, das von 2nd Quadrant entwickelt wurde. Dieses Tool hilft bei der Durchführung verschiedener Datenbankverwaltungsaktivitäten wie dem Erstellen und Überwachen der PostgreSQL-Replikation, einschließlich der Durchführung automatisierter Failover-Aktivitäten im Katastrophenfall, und hilft auch bei der Durchführung von Switchover-Operationen.

Repmgr ist ein einfach zu installierendes Tool und die Konfigurationen sind auch nicht komplex. Schauen wir uns zuerst die Installation an:

Repmgr installieren

Laden Sie das Tool hier herunter.

Entpacken Sie den Tarball und führen Sie die Installation wie unten gezeigt durch:

Ich habe repmgr-4.2.0 auf einem CentOS 7-Host installiert, und ich habe repmgr gegen PostgreSQL-11.1 installiert. Stellen Sie vor der Installation sicher, dass das PostgreSQL-bin-Verzeichnis Teil von $PATH und das PostgreSQL-lib-Verzeichnis Teil von $LD_LIBRARY_PATH ist. Um zu verstehen, dass der repmgr für PostgreSQL-11.1 installiert wird, zeige ich unten die Ausgabe „make install“ an:

[[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/'

repmgr für automatisches Failover konfigurieren

Bevor Sie sich mit der Konfiguration von „repmgr“ befassen, müssen die Datenbanken mit der Streaming-Replikation konfiguriert werden, die wir zuvor gesehen haben. Zunächst müssen beide Datenbanken (Primary und Standby) mit folgendem Parameter in der postgresql.conf konfiguriert werden:

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)

Der obige Parameter dient dazu, den „repmgrd“-Daemon zu aktivieren, der kontinuierlich im Hintergrund läuft und die Streaming-Replikation überwacht. Ohne diesen Parameter ist kein automatisches Failover möglich. Das Ändern dieses Parameters würde einen Neustart der Datenbank erfordern.
Erstellen Sie als Nächstes die repmgr-Konfigurationsdatei (z. B. mit dem Namen repmgr.conf) für beide Datenbanken. Die primäre Datenbank muss eine Konfigurationsdatei mit folgendem Inhalt haben:

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

Legen Sie die Datei im Datenverzeichnis ab, in diesem Fall „/data/pgdata11“.

Die Konfigurationsdatei der Standby-Datenbank muss folgenden Inhalt haben:

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

Beide Datenbanken müssen bei repmgr registriert werden.
Primäre Datenbank registrieren

[[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) registered

Standby-Datenbank registrieren

[[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 registered

Führen Sie den folgenden Befehl aus, um sicherzustellen, dass die repmgr-Protokollierung funktioniert.

[[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"

Wie Sie sehen können, habe ich log_level auf DEBUG konfiguriert, um eine detaillierte Protokollierung in der repmgr.conf-Datei des Standby-Servers zu generieren. Überprüfen Sie die Protokolle auf den Replikationsstatus.
Prüfen Sie mit repmgr:

, ob die Replikation wie erwartet funktioniert 
[[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=2

Die obige Meldung bestätigt, dass die Replikation einwandfrei läuft.

Wenn ich jetzt die primäre Datenbank herunterfahre, sollte der repmgrd-Daemon den Ausfall der primären Datenbank erkennen und die Standby-Datenbank hochstufen. Lassen Sie uns sehen, ob das passiert -Die primäre Datenbank wurde gestoppt:

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

Die Standby-Datenbank muss automatisch heraufgestuft werden. Die repmgr-Protokolle würden dasselbe zeigen:

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 primary

Das Obige bedeutet genau, dass repmgr keine Verbindung zur Primärdatenbank herstellen konnte und nach 5 erfolglosen Versuchen die Standby-Datenbank zur neuen Primärdatenbank hochgestuft wird. Unten sehen Sie, was die heraufgestuften Standby-Datenbankprotokolle (neue primäre Datenbank) zeigt:


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 connections

Ich habe nur die wichtigen Parameter in der repmgr-Konfigurationsdatei erwähnt. Es gibt viele andere Parameter, die modifiziert werden können, um verschiedenen Anforderungen gerecht zu werden. Die anderen wichtigen Parameter sind replication_lag_*-Parameter, wie unten gezeigt:

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgr überprüft die Schwellenwerte der oben genannten Parameter, bevor der Standby-Modus aktiviert wird. Wenn die Replikationsverzögerung kritisch ist, wird die Heraufstufung nicht fortgesetzt. Das ist wirklich gut, denn wenn der Standby-Modus bei einer Verzögerung hochgestuft wird, würde dies zu einem Datenverlust führen.

Die Anwendungen müssen sicherstellen, dass sie sich innerhalb des erwarteten Zeitrahmens erfolgreich wieder mit dem neu heraufgestuften Standby verbinden. Die Load Balancer könnten die App-Verbindungen umleiten, wenn die primäre Datenbank nicht mehr reagiert. Die andere Alternative wäre die Verwendung von Middleware-Tools wie PgPool-II, um sicherzustellen, dass alle Verbindungen erfolgreich umgeleitet werden.

Um sicherzustellen, dass eine Hochverfügbarkeitsarchitektur erfolgreich in der Produktion bereitgestellt wird, müssen gründliche End-to-End-Tests des gesamten Prozesses durchgeführt werden. Meiner Erfahrung nach bezeichnen wir diese Übung als DR DRILL. Das bedeutet, dass etwa alle 6 Monate ein Umschaltvorgang durchgeführt wird, um sicherzustellen, dass der Standby-Modus erfolgreich hochgestuft wird und die App-Verbindungen erfolgreich wieder mit dem hochgestuften Standby verbunden werden. Die vorhandene Primärdatenbank wird zu einer neuen Standby-Instanz. Sobald der Umschaltvorgang erfolgreich ist, werden Metriken aufgezeichnet, um zu sehen, dass die SLAs eingehalten werden.

Was ist Switchover?

Wie oben erläutert, ist Switchover eine geplante Aktivität, bei der die Rollen der primären und der Standby-Datenbank umgeschaltet werden. Das heißt, Standby wird primär und primär wird Standby. Mit repmgr kann dies erreicht werden. Unten ist, was repmgr tut, wenn der Switchover-Befehl ausgegeben wird.

$ 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 complete

Was kann repmgr sonst noch tun?

  • Repmgr kann helfen, die Standby-Datenbanken von Grund auf neu zu erstellen
  • Mehrere Standby-Datenbanken können mit einem laufenden Master erstellt werden
  • Kaskadierende Standbys können erstellt werden, was meiner Meinung nach vorteilhafter ist, als mehrere Standbys für eine Master-Datenbank zu konfigurieren

Was ist, wenn sowohl Primär als auch Standby weg sind?

Nun, das ist eine Situation, in der Unternehmen darüber nachdenken, mehrere Standby-Instanzen zu haben. Wenn sie alle weg sind, besteht der einzige Ausweg darin, die Datenbank aus den Sicherungen wiederherzustellen. Aus diesem Grund ist eine gute Backup-Strategie unerlässlich. Die Sicherungen müssen regelmäßig testweise wiederhergestellt und validiert werden, um sicherzustellen, dass die Sicherungen zuverlässig sind. Das Infrastrukturdesign für Backups muss so sein, dass die Wiederherstellung und Wiederherstellung der Backups nicht lange dauern darf. Der Wiederherstellungs- und Wiederherstellungsprozess der Backups muss innerhalb der festgelegten SLA abgeschlossen werden. SLAs für Backups sind in Bezug auf RTO (Recovery Time Objective) und RPO (Recovery Point Objective) konzipiert. Das heißt, RTO:Die Zeit, die zum Wiederherstellen und Wiederherstellen des Backups benötigt wird, muss innerhalb des SLA und RPO liegen:Bis zu welchem ​​​​Zeitpunkt die Wiederherstellung durchgeführt wurde, muss akzeptabel sein, mit anderen Worten, es ist Datenverlusttoleranz und im Allgemeinen sagen Unternehmen 0 Datenverlust Toleranz.

Schlussfolgerung

  • Geschäftskontinuität für PostgreSQL ist eine wichtige Voraussetzung für geschäftskritische Datenbankumgebungen. Dies zu erreichen, ist mit viel Planung und Kosten verbunden.
  • Ressourcen und Infrastruktur müssen optimal genutzt werden, um sicherzustellen, dass eine effiziente Notfallwiederherstellungsstrategie vorhanden ist.
  • Es könnte Herausforderungen aus Kostensicht geben, die beachtet werden müssen
  • Wenn das Budget es zulässt, stellen Sie sicher, dass mehrere DR-Standorte für ein Failover vorhanden sind
  • Falls die Sicherungen wiederhergestellt werden müssen, stellen Sie sicher, dass eine gute Sicherungsstrategie vorhanden ist.