Konfigurieren der verzögerten Replikation mit RDS für PostgreSQL - Amazon Relational Database Service
Übersicht und VorteileAktivieren und KonfigurierenVerwalten der Wiederherstellung von verzögerten ReplikationenÜberlegungen zur PlanungGrundlagen zu Einschränkungen

Konfigurieren der verzögerten Replikation mit RDS für PostgreSQL

Übersicht und Vorteile

Mit der verzögerten Replikation in RDS für PostgreSQL können Sie die Replikation von Datenänderungen von der Primärdatenbank auf einen oder mehrere Standbyserver (Lesereplikate) absichtlich verzögern. Dies bietet wertvollen Schutz vor beschädigten Daten, versehentlichem Datenverlust und fehlerhaften Transaktionen, die andernfalls sofort auf alle Replikate übertragen werden könnten.

Die verzögerte Replikation wird für die folgenden Versionen von RDS für PostgreSQL unterstützt:

  • 14.19 und höhere 14-Versionen

  • 15.14 und höhere 15-Versionen

  • 16.10 und höhere 16-Versionen

  • 17.6 und höhere 17-Versionen

Durch die Einführung einer Zeitverzögerung beim Replikationsprozess erhalten Sie die Möglichkeit, datenbezogene Vorfälle zu erkennen und darauf zu reagieren, bevor sie sich auf Ihren gesamten DB-Cluster auswirken. Hauptvorteile der verzögerten Replikation:

  • Ermöglicht die Wiederherstellung nach versehentlichen Löschvorgängen, Aktualisierungen oder anderen logischen Fehlern.

  • Bietet einen Puffer gegen die Ausbreitung beschädigter Daten im DB-Cluster.

  • Bietet einen möglichen zusätzlichen Wiederherstellungspunkt als Ergänzung zu herkömmlichen Backup-Strategien.

  • Ermöglicht es Ihnen, den Verzögerungszeitraum anhand der spezifischen Anforderungen und der Risikotoleranz Ihres Unternehmens zu konfigurieren.

Aktivieren und Konfigurieren der verzögerten Replikation

Führen Sie diese Schritte aus, um die verzögerte Replikation auf einem Lesereplikat von RDS für PostgreSQL zu aktivieren:

Anmerkung

Verwenden Sie für kaskadierte Lesereplikate denselben Parameter recovery_min_apply_delay und führen Sie die unten beschriebenen Schritte aus.

So aktivieren Sie die verzögerte Replikation

  1. Erstellen Sie eine neue benutzerdefinierte Parametergruppe oder ändern Sie eine vorhandene Parametergruppe. Weitere Informationen finden Sie unter DB-Parametergruppen für DB-Instances von Amazon RDS.

  2. Konfigurieren Sie den Parameter recovery_min_apply_delay in der Parametergruppe:

    • Legen Sie den Wert auf die gewünschte Verzögerung in Millisekunden fest. Zum Beispiel 3 600 000 für eine Verzögerung von 1 Stunde.

    • Zulässiger Bereich: 0 bis 86 400 000 ms (0 bis 24 Stunden)

    • Standard: 0

  3. Wenden Sie die Parametergruppe auf die Lesereplikat-Instance an, die Sie für die verzögerte Replikation konfigurieren möchten.

  4. Starten Sie die Lesereplikat-Instance neu, damit die Änderungen wirksam werden.

    Anmerkung

    Der recovery_min_apply_delay-Parameter ist dynamisch. Wenn Sie eine vorhandene Parametergruppe ändern, die bereits mit der Instance verknüpft ist, werden die Änderungen sofort wirksam, ohne dass ein Neustart erforderlich ist. Wenn Sie jedoch eine neue Parametergruppe auf die Instance anwenden, müssen Sie einen Neustart vornehmen, damit die Änderungen wirksam werden.

Verwalten der Wiederherstellung von verzögerten Replikationen

Eine verzögerte Replikation ist besonders nützlich für Szenarien, bei denen herkömmliche zeitpunktbezogene Wiederherstellungsmethoden möglicherweise unzureichend oder zu zeitaufwändig sind.

Während des Zeitraums der verzögerten Replikation können Sie die folgenden PostgreSQL-Funktionen zum Verwalten des Wiederherstellungsprozesses verwenden:

  • pg_wal_replay_pause(): Fordert die Unterbrechung des Wiederherstellungsprozesses für das verzögerte Replikat an.

  • pg_wal_replay_resume(): Startet den Wiederherstellungsprozess neu, sofern er zuvor unterbrochen wurde.

  • pg_is_wal_replay_paused(): Überprüft, ob der Wiederherstellungsprozess derzeit unterbrochen ist.

  • pg_get_wal_replay_pause_state(): Ruft den aktuellen Status des Wiederherstellungsprozesses ab (nicht unterbrochen, Unterbrechung angefordert oder unterbrochen).

Benutzer mit der Rolle rds_superuser haben EXECUTE-Berechtigungen für pg_wal_replay_pause() und pg_wal_replay_resume(). Wenn andere Datenbankbenutzer Zugriff auf diese Funktionen benötigen, müssen Sie ihnen die Rolle rds_superuser gewähren. Weitere Informationen zur rds_superuser-Rolle finden Sie unter Die Rolle „rds_superuser“ verstehen.

Für den Zugriff auf andere Funktionen wie pg_is_wal_replay_paused() und pg_get_wal_replay_pause_state() ist die rds_superuser Rolle nicht erforderlich.

Sie können die folgenden Wiederherstellungszielparameter verwenden, um den Zeitpunkt, bis zu dem das verzögerte Replikat wiederhergestellt wird, genau zu steuern. Diese Parameter sind statisch und erfordern einen Neustart der Datenbank, damit die Änderungen wirksam werden:

  • recovery_target

  • recovery_target_lsn

  • recovery_target_name

  • recovery_target_time

  • recovery_target_xid

  • recovery_target_inclusive

Wichtig

Sie können jeweils nur einen Wiederherstellungszielparameter angeben. Die Konfiguration mehrerer Wiederherstellungszielparameter in der Konfigurationsdatei führt zu einem Fehler.

Überlegungen zur Planung

Berücksichtigen Sie bei der Planung der verzögerten Replikation mit RDS für PostgreSQL folgende Aspekte:

  • Während der automatischen Rotation der rdsrepladmin-Anmeldeinformationen (die alle 90 Tage erfolgt) können verzögerte Lesereplikate vorübergehend in den Status REPLICATION_ERROR wechseln. Wenn das verzögerte Replikat über genügend WAL-Protokolle verfügt, um die konfigurierte Verzögerung beizubehalten, kann der WAL-Empfängerprozess unterbrochen werden, was zu einer WAL-Akkumulation auf der Quelle führt. Sie sollten den Replikationsstatus auf dem Replikat und die Speichernutzung auf der Quelle überwachen, um zu verhindern, dass der Speicherplatz voll wird.

  • Wenn bei verzögerten Lesereplikaten Systemereignisse (wie Hochfahren oder Neustart) auftreten, wechseln sie in den Status REPLICATION_ERROR, in dem der WAL-Empfängerprozess inaktiv bleibt, bis der konfigurierte Verzögerungszeitraum abläuft. Dieses Verhalten kann zu einer WAL-Akkumulation auf der Quell-Instance führen, was möglicherweise einen vollen Speicher verursachen kann. Berücksichtigen Sie die folgenden vorbeugenden Maßnahmen:

    • Konfigurieren Sie CloudWatch-Alarme, um die Speichernutzung auf Quell-Instances zu überwachen.

    • Aktivieren Sie die automatische Speicherskalierung, um eine unerwartete WAL-Expansion zu verarbeiten.

    • Legen Sie den Parameter max_slot_wal_keep_size auf der Quell-Instance fest, um die WAL-Beibehaltung pro Replikations-Slot zu begrenzen.

    • Überwachen Sie die Replikationsverzögerung und den Status des Replikations-Slots regelmäßig.

  • Längere Verzögerungen erhöhen die Anzahl der WAL-Protokolle auf den Replikaten und belegen dadurch mehr Speicherplatz. Überwachen Sie den Speicherplatz mithilfe von CloudWatch-Alarmen, aktivieren Sie die automatische Skalierung oder erfassen Sie bei Bedarf Replikate.

  • Bei der Heraufstufung eines verzögerten Lesereplikats wird der Parameter recovery_min_apply_delaynicht berücksichtigt und alle ausstehenden WAL-Datensätze werden sofort angewendet.

  • Der Parameter recovery_min_apply_delay ist unabhängig von den einzelnen Ebenen einer kaskadierenden Replikationseinrichtung. Durch das Festlegen einer Verzögerung für ein Replikat nimmt die Verzögerung kaskadierter Replikate nicht zu.

Weitere Informationen finden Sie in der Dokumentation zu Lesereplikaten von RDS für PostgreSQL und in der Dokumentation zur Notfallwiederherstellung von RDS für PostgreSQL.

Grundlagen zu Einschränkungen

Die verzögerte Replikation für Amazon RDS für PostgreSQL hat die folgenden Einschränkungen:

  • Für Blau/Grün-Bereitstellungen gelten bei der Konfiguration der verzögerten Replikation die folgenden Einschränkungen:

    • Grüne Quell-Instance – Der Parameter recovery_min_apply_delay parameter wird ignoriert, auch wenn er in der Parametergruppe konfiguriert ist. Alle Verzögerungseinstellungen auf der grünen Quell-Instance werden nicht wirksam.

    • Grüne Replikat-Instance – Der Parameter recovery_min_apply_delay parameter wird vollständig unterstützt und auf die PostgreSQL-Konfigurationsdatei angewendet. Die Verzögerungseinstellungen funktionieren während des Umstellungs-Workflows erwartungsgemäß.

    • Blau/Grün-Bereitstellungen von RDS für Hauptversions-Upgrades

  • Bei Hauptversions-Upgrades werden alle verzögerten Lesereplikate automatisch beendet, damit die Quell-Instance mit dem Upgrade fortfahren kann, um für minimale Ausfallzeiten zu sorgen. Nachdem die Quell-Instance das Upgrade abgeschlossen hat, müssen Sie die verzögerten Replikate manuell neu erstellen.

  • Die verzögerte Replikation ist mit den folgenden Features nicht kompatibel.

    • Logische Replikation von RDS für PostgreSQL

    • Multi-AZ-Cluster von RDS für PostgreSQL (einschließlich der eingehenden und ausgehenden Replikation)

    • Aurora PostgreSQL