Daten mit Sicherungen schützen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird die Referenzarchitektur für die AlloyDB Omni-Standardverfügbarkeit beschrieben, die Datenschutz mithilfe von Sicherungen bietet.

Anwendungsfälle

Diese Referenzarchitektur unterstützt die folgenden Szenarien:

  • Sie haben Datenbanken, die eine gewisse Ausfallzeit und einen gewissen Datenverlust seit der letzten Sicherung tolerieren können.
  • Sie möchten Ihre AlloyDB Omni-Datenbank vor Benutzerfehlern, Beschädigungen oder physischen Fehlern auf Datenbankebene schützen (im Gegensatz zu Server- oder VM-Image-Snapshots).
  • Sie möchten Ihre Datenbank lokal oder remote wiederherstellen können, möglicherweise bis zu einem bestimmten Zeitpunkt.

Funktionsweise der Referenzarchitektur

Die Referenzarchitektur für Standardverfügbarkeit deckt die Sicherung und Wiederherstellung Ihrer AlloyDB Omni-Datenbanken ab, unabhängig davon, ob sie als eigenständige Instanz auf einem Hostserver, als virtuelle Maschine (AlloyDB Omni installieren) oder in einem Kubernetes-Cluster (AlloyDB Omni in Kubernetes installieren) ausgeführt werden.

Die Standardverfügbarkeit ist eine einfache Implementierung, bei der weniger zusätzliche Hardware oder Dienste erforderlich sind. Das Recovery Time Objective (RTO) steigt jedoch mit der Größe der Datenbank. Je mehr Daten gesichert werden müssen, desto länger dauert es, die Datenbank wiederherzustellen. Der Datenverlust hängt vom Typ der Sicherung ab. Wenn nur Datendateien regelmäßig gesichert werden, kommt es bei der Wiederherstellung zu Datenverlusten seit der letzten Sicherung.

RPO reduzieren

Mit der Funktion kontinuierliche Archivierung von PostgreSQL können Sie ein niedriges Recovery Point Objective (RPO) erreichen und die Wiederherstellung zu einem bestimmten Zeitpunkt über Sicherungen ermöglichen. Dabei werden Write-Ahead-Logging-Dateien (WAL) archiviert und WAL-Daten gestreamt, möglicherweise an einen Remote-Speicherstandort.

Wenn die Archivierung von WAL-Dateien nur in bestimmten Intervallen vorgenommen wird oder wenn sie voll sind, beschränkt ein vollständiger Datenbankverlust (einschließlich der aktuellen WAL-Dateien) die Wiederherstellung auf die letzte archivierte WAL-Datei. Das bedeutet, dass das Recovery Point Objective (RPO) einen potenziellen Datenverlust berücksichtigen muss. Umgekehrt maximiert die kontinuierliche WAL-Datenübertragung die Möglichkeit, einen Datenverlust komplett zu vermeiden.

Wenn Sie kontinuierliche Sicherungen vornehmen, können Sie eine Wiederherstellung zu einem bestimmten Zeitpunkt ausführen. Durch die Wiederherstellung zu einem bestimmten Zeitpunkt können Sie den Zustand vor einem Fehler wiederherstellen, z. B. vor dem versehentlichen Löschen einer Tabelle oder vor falschen Batch-Updates. Diese Wiederherstellungsmethode wirkt sich jedoch auf das Recovery Point Objective (RPO) aus, sofern keine temporäre Hilfsdatenbank verwendet wird.

Sicherungsstrategien

Sie können AlloyDB Omni-Sicherungen auf Postgres-Ebene so konfigurieren, dass sie entweder im lokalen oder im Remote-Speicher gespeichert werden. Lokaler Speicher ist zwar möglicherweise schneller zu sichern und wiederherzustellen, aber Remote-Speicher ist in der Regel robuster, wenn ein ganzer Host oder eine ganze VM ausfällt.

Sicherungen in Nicht-Kubernetes-Umgebungen

Bei Nicht-Kubernetes-Bereitstellungen können Sie Sicherungen mit den folgenden PostgreSQL-Tools planen:

Alternativ können Sie für kleine Datenbanken eine logische Sicherung der Datenbank durchführen (mit pg_dump für eine einzelne Datenbank oder pg_dumpall für den gesamten Cluster). Sie können die Wiederherstellung mithilfe von pg_restore ausführen.

Sicherungen in Kubernetes mit dem AlloyDB Omni-Operator

Für AlloyDB Omni, das in einem Kubernetes-Cluster bereitgestellt ist, können Sie kontinuierliche Sicherungen mit einem Sicherungsplan für jeden Datenbankcluster konfigurieren. Weitere Informationen finden Sie unter Sichern und Wiederherstellen in Kubernetes.

Sie können AlloyDB Omni-Sicherungen lokal oder remote in Cloud Storage speichern, einschließlich der Optionen, die von einem beliebigen Cloud-Anbieter bereitgestellt werden. Weitere Informationen finden Sie in Abbildung 1, in der potenzielle Sicherungsziele dargestellt sind.

AlloyDB Omni mit Sicherungsoptionen

Abbildung 1. AlloyDB Omni mit Sicherungsoptionen

Sicherungen können entweder auf lokalen oder Remote-Speicheroptionen erstellt werden. Lokale Sicherungen sind normalerweise schneller, da sie nur auf dem E/A-Durchsatz basieren, während Remote-Sicherungen in der Regel eine höhere Latenz und eine geringere Netzwerkbandbreite haben. Remote-Sicherungen bieten jedoch optimalen Schutz, auch bei zonalen Ausfällen.

Sie können lokale Sicherungen auch auf lokalen oder freigegebenen Speicher aufteilen. Lokale Speicheroptionen sind von fehlenden Optionen zur Notfallwiederherstellung betroffen, wenn ein Datenbankhost ausfällt. Bei freigegebenem Speicher kann dieser Speicher auf einen anderen Server verlagert und dann für die Wiederherstellung verwendet werden. Das bedeutet, dass das RTO bei freigegebenem Speicher möglicherweise kürzer ist.

Bei Bereitstellungen mit lokalem und freigegebenem Speicher können die folgenden Arten von Sicherungen geplant oder manuell on demand erstellt werden:

  • Vollsicherungen: vollständige Sicherungen aller Datenbankdateien, die für die Datenwiederherstellung erforderlich sind.
  • Differenzielle Sicherungen: Sicherungen nur der Dateiänderungen seit der letzten Vollsicherung.
  • Inkrementelle Sicherungen: Sicherungen nur der Dateiänderungen seit der letzten Sicherung jeglicher Art.

Wiederherstellung zu einem bestimmten Zeitpunkt

Kontinuierliche Sicherungen der PostgreSQL-WAL-Dateien (Write-Ahead Logging) unterstützen die Wiederherstellung zu einem bestimmten Zeitpunkt. Wenn die WAL-Dateien nach einem Fehlerereignis intakt und verwendbar sind, können Sie sie zur Wiederherstellung ohne Datenverlust verwenden.

Sie können die folgenden Parameter konfigurieren, um das Schreiben der WAL-Dateien zu steuern:

Parameter Beschreibung

wal_writer_delay

Gibt an, wie oft der WAL-Writer das WAL auf das Laufwerk leert, sofern der Schreibvorgang nicht früher durch eine Transaktion reaktiviert wird, die asynchrone Commits ausführt. Der Standardwert ist 200 ms. Durch Erhöhen dieses Werts wird die Häufigkeit von Schreibvorgängen verringert, aber die Menge der Daten, die bei einem Serverabsturz verloren gehen, kann zunehmen.

wal_writer_flush_after

Gibt an, wie viele WAL-Daten sich ansammeln können, bevor der WAL-Writer ein Leeren auf das Laufwerk erzwingt. Der Standardwert ist 1 MB. Wenn der Wert auf null gesetzt ist, werden WAL-Daten immer sofort auf das Laufwerk geleert.

synchronous_commit

Gibt an, ob der Commit eine Antwort an den Nutzer zurückgibt, bevor die WAL-Daten auf das Laufwerk geschrieben werden. Die Standardeinstellung ist on. Dadurch wird sichergestellt, dass die Transaktion dauerhaft ist. Mit anderen Worten: Der Commit wurde auf das Laufwerk geschrieben, bevor ein Erfolgscode an den Nutzer zurückgegeben wurde. Bei der Einstellung off gibt es bis zu dreimal wal_writer_delay, bevor die Transaktion auf das Laufwerk geschrieben wird.

Überwachung der WAL-Nutzung

Sie haben folgende Möglichkeiten, die WAL-Nutzung zu beobachten:

Beobachtungsmethode Beschreibung

pg_stat_wal

Diese Standardansicht enthält die Spalten wal_write und wal_sync, in denen die Anzahl der WAL-Schreibvorgänge und WAL-Synchronisierungen gespeichert ist. Wenn der Konfigurationsparameter track_wal_io_timing aktiviert ist, werden auch wal_write_time und wal_sync_time gespeichert. Regelmäßige Snapshots dieser Ansicht können helfen, die WAL-Schreibvorgangs- und Synchronisierungsaktivität im Zeitverlauf darzustellen.
pg_current_wal_lsn() Diese Funktion gibt die aktuelle Position der Logsequenznummer (LSN) zurück. Wenn diese mit einem Zeitstempel verknüpft und im Zeitverlauf als Snapshots erfasst wird, kann sie die Byte/Sekunde-Angabe des WAL liefern, die mit der Funktion pg_wal_lsn_diff(lsn1, lsn2) generiert wird. Diese Funktion ist ein nützlicher Messwert, um die Transaktionsrate und die Leistung der WAL-Dateien zu verstehen.

WAL-Daten an einen Remote-Standort streamen

Wenn Sie Barman verwenden, können die WAL-Daten auch so eingerichtet werden, dass sie in Echtzeit an einen Remote-Standort gestreamt werden, um sicherzustellen, dass bei der Wiederherstellung nur wenige oder gar keine Daten verloren gehen. Trotz des Streamings in Echtzeit besteht eine geringe Wahrscheinlichkeit, dass Transaktionen, für die ein Commit durchgeführt wurde, verloren gehen, da die Streaming-Schreibvorgänge auf dem Remote-Barman-Server standardmäßig asynchron sind. Es ist jedoch möglich, WAL-Streaming im synchronen Modus einzurichten, in dem das WAL gespeichert und eine Statusantwort an die Quelldatenbank zurückgesendet wird. Beachten Sie, dass dieser Ansatz Transaktionen verlangsamen kann, sofern sie warten müssen, bis dieser Schreibvorgang abgeschlossen ist, bevor sie fortgesetzt werden können.

Sicherungszeitpläne

In den meisten Umgebungen werden Sicherungen in der Regel wöchentlich geplant. Im Folgenden finden Sie einen typischen wöchentlichen Plan für Sicherungen:

  • Sonntag: Vollsicherung
  • Montag, Dienstag: Sicherung
  • Mittwoch: differenzielle Sicherung
  • Donnerstag, Freitag: inkrementelle Sicherung
  • Samstag: differenzielle Sicherung

Bei der Verwendung dieses typischen Zeitplans ist für ein fortlaufendes Wiederherstellungsfenster von einer Woche Speicherplatz für bis zu drei Vollsicherungen sowie die erforderlichen inkrementellen oder differenziellen Sicherungen erforderlich. Dieser Ansatz unterstützt die Wiederherstellung nach einem Fehler, der während der Vollsicherung am Sonntag auftritt. Die Datenbankwiederherstellung muss bis zum vorherigen Sonntag vor dem Start der Sicherung erfolgen.

Um das RTO bei einem potenziell höheren RPO zu minimieren, können zusätzliche Datenbanken im kontinuierlichen Wiederherstellungsmodus betrieben werden. Dazu müssen Sicherungen wiederholt und die sekundäre Umgebung kontinuierlich aktualisiert werden, indem neue WAL-Dateien archiviert und wiederholt werden. Das tatsächliche RPO, das den potenziellen Datenverlust widerspiegelt, hängt von der Transaktionshäufigkeit, der WAL-Dateigröße und der Verwendung von WAL-Streaming ab.

Wiederherstellen in Nicht-Kubernetes-Umgebungen

Bei Nicht-Kubernetes-Bereitstellungen müssen Sie zum Wiederherstellen einer AlloyDB Omni-Datenbank entweder den Docker-Container beenden und dann Daten wiederherstellen oder die Daten an einem anderen Speicherort wiederherstellen und eine neue Docker-Instanz mit diesen wiederhergestellten Daten starten. Nach dem Neustart des Containers ist die Datenbank mit den wiederhergestellten Daten zugänglich.

Weitere Informationen zu Wiederherstellungsoptionen finden Sie unter AlloyDB Omni-Cluster mit pgBackRest wiederherstellen und AlloyDB Omni-Cluster mit Barman wiederherstellen.

Wiederherstellen in Kubernetes mit Operator

Zum Wiederherstellen einer Datenbank in Kubernetes bietet der Operator die Wiederherstellung im selben Kubernetes-Cluster und ‑Namespace aus einer benannten Sicherung oder einem Klon von einem bestimmten Zeitpunkt (point in time, PIT). Wenn Sie eine Datenbank in einen anderen Kubernetes-Cluster klonen möchten, verwenden Sie pgBackRest. Weitere Informationen finden Sie unter Sichern und Wiederherstellen in Kubernetes und Datenbankcluster aus einer Kubernetes-Sicherung klonen – Übersicht.

Implementierung

Wenn Sie eine Referenzarchitektur für die Verfügbarkeit auswählen, sollten Sie die folgenden Vorteile, Einschränkungen und Alternativen berücksichtigen.

Vorteile

  • Einfach zu verwenden und zu verwalten und für nicht kritische Datenbanken mit tolerantem RTO/RPO geeignet
  • Nur minimale zusätzliche Hardware erforderlich
  • Sicherungen sind immer für einen vollständigen Notfallwiederherstellungsplan erforderlich
  • Wiederherstellung zu einem beliebigen Zeitpunkt innerhalb des Wiederherstellungszeitraums ist möglich

Beschränkungen

  • Speicheranforderungen, die je nach Aufbewahrungsanforderungen möglicherweise größer als die Datenbank selbst sind
  • Wiederherstellung kann lange dauern und zu einem höheren RTO führen
  • Kann je nach Verfügbarkeit der aktuellen WAL-Daten nach einem Datenbankfehler zu einem gewissen Datenverlust führen, was sich negativ auf den RPO auswirken kann

Alternativen

  • Erwägen Sie die erweiterte oder Premium-Verfügbarkeitsarchitektur, um die Verfügbarkeit und die Optionen zur Notfallwiederherstellung zu verbessern.

Nächste Schritte