Bewährte Methoden für Aurora blue/green Aurora-Bereitstellungen - Amazon Aurora
Allgemeine bewährte Methoden für Bereitstellungen blue/green — Bewährte Methoden für blue/green BereitstellungenBewährte Methoden für Bereitstellungen von Aurora PostgreSQL blue/green Bewährte Methoden Aurora Global Database

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für Aurora blue/green Aurora-Bereitstellungen

Im Folgenden finden Sie bewährte Methoden für blue/green Bereitstellungen.

Allgemeine bewährte Methoden für Bereitstellungen blue/green

Beachten Sie die folgenden allgemeinen bewährten Methoden, wenn Sie eine Blau/Grün-Bereitstellung erstellen.

  • Testen Sie den Aurora-DB-Cluster in der grünen Umgebung gründlich, bevor Sie umstellen.

  • Halten Sie Ihre Datenbanken in der grünen Umgebung schreibgeschützt. Wir empfehlen, Schreibvorgänge in der grünen Umgebung mit Vorsicht zu aktivieren, da sie zu Replikationskonflikten führen können. Sie können auch zu ungewollten Daten in den Produktionsdatenbanken nach der Umstellung führen.

  • Wenn Sie eine blue/green Bereitstellung verwenden, um Schemaänderungen zu implementieren, nehmen Sie nur replikationskompatible Änderungen vor.

    Sie können beispielsweise am Ende einer Tabelle neue Spalten hinzufügen, ohne die Replikation von der blauen zur grünen Bereitstellung zu unterbrechen. Schemaänderungen, wie das Umbenennen von Spalten oder Tabellen, führen jedoch dazu, dass die Replikation zur Grün-Bereitstellung unterbrochen wird.

    Weitere Informationen zu replikationskompatiblen Änderungen finden Sie in der MySQL-Dokumentation unter Replikation mit unterschiedlichen Tabellendefinitionen auf Quelle und Replikat sowie unter Einschränkungen in der Dokumentation zur logischen Replikation in PostgreSQL.

  • Verwenden Sie den Cluster-Endpunkt, den Reader-Endpunkt oder den benutzerdefinierten Endpunkt für alle Verbindungen in beiden Umgebungen. Verwenden Sie keine Instance-Endpunkte oder benutzerdefinierten Endpunkte mit statischen oder Ausschlusslisten.

  • Wenn Sie zu einer blue/green Bereitstellung wechseln, befolgen Sie die bewährten Methoden für den Switchover. Weitere Informationen finden Sie unter Bewährte Methoden für die Umstellung.

— Bewährte Methoden für blue/green Bereitstellungen

Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blue/green Bereitstellung aus einem Aurora MySQL-DB-Cluster einer erstellen.

  • Wenn es in der grünen Umgebung zu Replikatverzögerungen kommt, sollten Sie die folgenden Schritte ausführen:

    • Deaktivieren Sie die Aufbewahrung von Binärprotokollen, falls sie nicht benötigt wird, oder deaktivieren Sie sie vorübergehend, bis die Replikation abgeschlossen ist. Setzen Sie dazu den binlog_format-DB-Cluster-Parameter wieder auf 0 und starten Sie die grüner Schreiber-DB-Instance neu.

    • Setzen Sie den Parameter innodb_flush_log_at_trx_commit in der grünen DB-Parametergruppe vorübergehend auf 0. Wenn die Replikation aufgeholt hat, kehren Sie zum Standardwert 1 vor der Umstellung zurück. Wenn der temporäre Parameterwert unerwartet heruntergefahren wird oder es zu einem Absturz kommt, erstellen Sie die grüne Umgebung neu, um unentdeckte Datenbeschädigungen zu vermeiden. Weitere Informationen finden Sie unter Konfigurieren, wie oft der Protokollpuffer geleert wird.

Bewährte Methoden für Bereitstellungen von Aurora PostgreSQL blue/green

Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blue/green Bereitstellung aus einem Aurora PostgreSQL-DB-Cluster erstellen.

  • Überwachen Sie den Write-Through-Cache für die logische Replikation in Aurora PostgreSQL und nehmen Sie gegebenenfalls Anpassungen am Cache-Puffer vor. Weitere Informationen finden Sie unter Überwachen des Write-Through-Caches für die logische Replikation in Aurora PostgreSQL.

  • Erhöhen Sie den Wert des logical_decoding_work_mem-DB-Parameters in der blauen Umgebung. Dadurch muss auf der Festplatte weniger dekodiert werden und stattdessen wird Arbeitsspeicher beansprucht. Weitere Informationen finden Sie unter Arbeitsspeicher für logische Dekodierung anpassen.

    • Mithilfe der Metrik können Sie den Transaktionsüberlauf überwachen, der auf die Festplatte geschrieben wird. ReplicationSlotDiskUsage CloudWatch Diese Metrik bietet Einblicke in die Festplattennutzung von Replikations-Slots und hilft so, zu erkennen, wann Transaktionsdaten die Speicherkapazität überschreiten und auf der Festplatte gespeichert werden. Mit der Metrik können Sie den FreeableMemory CloudWatch freien Speicher überwachen. Weitere Informationen finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

    • In Aurora PostgreSQL Version 14 und höher können Sie die Größe von logischen Überlaufdateien mithilfe der Systemansicht pg_stat_replication_slots überwachen.

  • Aktualisieren Sie alle Ihre PostgreSQL-Erweiterungen auf die neueste Version, bevor Sie ein blue/green Deployment erstellen. Weitere Informationen finden Sie unter Aktualisieren von PostgreSQL-Erweiterungen.

  • Wenn Sie die aws_s3-Erweiterung verwenden, gewähren Sie dem grünen DB-Cluster über eine IAM-Rolle Zugriff auf Amazon S3, nachdem die grüne Umgebung erstellt wurde. Dadurch können die Import- und Exportbefehle auch nach der Umstellung weiter funktionieren. Detaillierte Anleitungen finden Sie unter Einrichten des Zugriffs auf einen Amazon-S3-Bucket.

  • Wenn Sie eine höhere Engine-Version für die grüne Umgebung angeben, führen Sie den ANALYZE-Vorgang für alle Datenbanken aus, um die pg_statistic-Tabelle zu aktualisieren. Optimizer-Statistiken werden während eines Hauptversions-Upgrades nicht übertragen, daher müssen Sie alle Statistiken neu generieren, um Leistungsprobleme zu vermeiden. Weitere bewährte Methoden bei Upgrades von Hauptversionen finden Sie unter Durchführen eines Hauptversions-Upgrades.

  • Vermeiden Sie es, Trigger als ENABLE REPLICA oder ENABLE ALWAYS zu konfigurieren, wenn der Trigger auf der Quelle zur Datenmanipulation verwendet wird. Andernfalls überträgt das Replikationssystem die Änderungen und führt den Trigger aus, was zu Duplikaten führt.

  • Transaktionen mit langer Laufzeit können zu erheblichen Verzögerungen bei der Replikation führen. Um die Replikationsverzögerung zu verringern, sollten Sie Folgendes in Betracht ziehen:

    • Reduzieren Sie lang andauernde Transaktionen und Untertransaktionen, die verzögert werden können, bis die grüne Umgebung die blaue Umgebung eingeholt hat.

    • Reduzieren Sie Massenoperationen in der blauen Umgebung, bis die grüne Umgebung die blaue Umgebung eingeholt hat.

    • Initiieren Sie vor der Erstellung der Bereitstellung einen manuellen Vakuum-Freeze-Vorgang für ausgelastete Tabellen. blue/green Eine Anleitung dazu finden Sie unter Durchführen einer manuellen Bereinigungseinfrierung.

    • Deaktivieren Sie in PostgreSQL Version 12 und höher den Parameter index_cleanup für große oder stark frequentierte Tabellen, um die Effizienz der regelmäßigen Wartung von blauen Datenbanken zu verbessern. Weitere Informationen finden Sie unter Möglichst schnelles Bereinigen einer Tabelle.

      Anmerkung

      Wenn die Indexbereinigung während des Bereinigens regelmäßig übersprungen wird, kann dies zu einer Überlastung des Index führen, wodurch die Scanleistung beeinträchtigt werden kann. Es hat sich bewährt, diesen Ansatz nur während einer blue/green Bereitstellung zu verwenden. Sobald die Bereitstellung abgeschlossen ist, empfehlen wir, die regelmäßige Indexwartung und -bereinigung wieder aufzunehmen.

    • Replikatverzögerungen können auftreten, wenn die blauen und grünen DB-Instances für die Workload zu klein sind. Stellen Sie sicher, dass Ihre DB-Instances ihre Ressourcengrenzen für den Instance-Typ nicht erreichen. Weitere Informationen finden Sie unter Verwendung von CloudWatch Amazon-Metriken zur Analyse der Ressourcennutzung für Aurora PostgreSQL.

  • Eine langsame Replikation kann dazu führen, dass Sender und Empfänger häufig neu gestartet werden, was die Synchronisierung verzögert. Um sicherzustellen, dass sie aktiv bleiben, deaktivieren Sie Timeouts, indem Sie den Parameter wal_sender_timeout in der blauen Umgebung auf 0 und den Parameter wal_receiver_timeout in der grünen Umgebung auf 0 setzen.

  • Überprüfen Sie die Leistung Ihrer UPDATE- und DELETE-Anweisungen und bewerten Sie, ob das Erstellen eines Indexes für die in der WHERE-Klausel verwendete Spalte diese Abfragen optimieren kann. Dies kann die Leistung verbessern, wenn die Vorgänge in der grünen Umgebung erneut ausgeführt werden. Weitere Informationen finden Sie unter Überprüfen Sie Prädikatfilter auf Abfragen, die Wartezeiten generieren.

  • Wenn Sie Trigger verwenden, stellen Sie sicher, dass sie das Erstellen, Aktualisieren und Löschen von pg_catalog.pg_publication-, pg_catalog.pg_subscription- und pg_catalog.pg_replication_slots-Objekten, deren Namen mit „rds“ beginnen, nicht beeinträchtigen.

  • Wenn Babelfish auf dem Quell-DB-Cluster aktiviert ist, müssen die folgenden Parameter in der Ziel-DB-Cluster-Parametergruppe für die grüne Umgebung dieselben Einstellungen haben wie in der Parametergruppe des Quell-DB-Clusters:

    • rds.babelfish_status

    • babelfishpg_tds.tds_default_numeric_precision

    • babelfishpg_tds.tds_default_numeric_scale

    • babelfishpg_tsql.default_locale

    • babelfishpg_tsql.migration_mode

    • babelfishpg_tsql.server_colation_name

    Weitere Informationen zu diesen Parametern finden Sie unter Einstellungen der DB-Cluster-Parametergruppe für Babelfish.

Bewährte Methoden Aurora Global Database

Zusätzlich zu den oben aufgeführten allgemeinen und Engine-spezifischen Best Practices sollten Sie die folgenden Best Practices für die Aurora Global Database berücksichtigen.

  • Überwachen Sie die folgenden CloudWatch Kennzahlen, um Perioden geringer Aktivität in Ihrer Produktionsumgebung zu identifizieren:

    • DatabaseConnections

    • ActiveTransactions

    Planen Sie den blue/green Switchover während Ihres geplanten Wartungsfensters oder während einer Phase geringer Aktivität.

  • Blue/Green switchover duration varies based on your workload and the number of secondary regions. When you initiate a blue/greenSwitchover: Der Service wartet, bis die Replikatverzögerung Null erreicht hat, bevor er fortfährt. Es wird empfohlen, die Replikatverzögerung zu überprüfen, bevor Sie einen Switchover einleiten.

  • Wenn Sie beabsichtigen, für Ihre grüne Umgebung einen anderen DB-Parameter oder eine andere DB-Cluster-Parametergruppe als die Standardparametergruppe zu verwenden, erstellen Sie die gewünschte Parametergruppe mit demselben Namen in allen sekundären Regionen, bevor Sie die Bereitstellung initiieren. blue/green