Bewährte Methoden für Blau/Grün-Bereitstellungen - Amazon Aurora
Allgemeine bewährte Methoden für blaue/grüne Bereitstellungen Best Practices für blaue/grüne BereitstellungenSQLBewährte Methoden von Aurora Postgre für blaue/grüne Bereitstellungen

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 Blau/Grün-Bereitstellungen

Im Folgenden finden Sie bewährte Methoden für blaue/grüne Bereitstellungen.

Allgemeine bewährte Methoden für blaue/grüne Bereitstellungen

Beachten Sie bei der Erstellung einer Blau/Grün-Bereitstellung die folgenden allgemeinen bewährten Methoden.

  • 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 Blau/Grün-Bereitstellung zur Implementierung von Schemaänderungen verwenden, nehmen Sie nur replikationskompatible Änderungen vor.

    Sie können beispielsweise neue Spalten am Ende einer Tabelle 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 unter Replikation mit unterschiedlichen Tabellendefinitionen für Quelle und Replikat in der SQL Dokumentation Meine Dokumentation und Einschränkungen in der Dokumentation zur logischen SQL Postgre-Replikation.

  • 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 auf eine Blau/Grün-Bereitstellung umstellen, befolgen Sie die bewährten Methoden für die Umstellung. Weitere Informationen finden Sie unter Bewährte Methoden für die Umstellung.

Best Practices für blaue/grüne Bereitstellungen

Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blaue/grüne Bereitstellung aus einem Aurora My DB-Cluster erstellen.

  • Wenn es in der grünen Umgebung zu Verzögerungen bei der Replikation kommt, sollten Sie Folgendes berücksichtigen:

    • 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 Green Writer-DB-Instance neu.

    • Setzen Sie den innodb_flush_log_at_trx_commit Parameter in der grünen DB-Parametergruppe vorübergehend auf 1. Wenn die Replikation aufgeholt hat, kehren Sie vor dem Switchover zu den Standardwerten zurück. Wenn es bei den temporären Parameterwerten zu einem unerwarteten Herunterfahren oder 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.

SQLBewährte Methoden von Aurora Postgre für blaue/grüne Bereitstellungen

Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blaue/grüne Bereitstellung aus einem Aurora SQL Postgre-DB-Cluster erstellen.

  • Überwachen Sie den Write-Through-Cache für die SQL logische Replikation von Aurora Postgre und nehmen Sie bei Bedarf Anpassungen am Cache-Puffer vor. Weitere Informationen finden Sie unter Überwachung des Write-Through-Cache für die SQL logische Replikation von Aurora Postgre.

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

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

  • Aktualisieren Sie alle Ihre SQL Postgre-Erweiterungen auf die neueste Version, bevor Sie eine blaue/grüne Bereitstellung erstellen. Weitere Informationen finden Sie unter Aktualisierung von Postgre-Erweiterungen SQL.

  • 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 Anweisungen 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 größeren Versionsupgrades nicht übertragen. Sie müssen daher alle Statistiken neu generieren, um Leistungsprobleme zu vermeiden. Weitere bewährte Methoden bei größeren Versionsupgrades finden Sie unter. Durchführen eines Hauptversions-Upgrades

  • Vermeiden Sie es, Trigger so zu konfigurieren, als ENABLE REPLICA ENABLE ALWAYS ob der Trigger auf der Quelle verwendet wird, um Daten zu manipulieren. Andernfalls leitet das Replikationssystem die Änderungen weiter und führt den Trigger aus, was zu Duplizierungen führt.

  • Transaktionen mit langer Laufzeit können zu erheblichen Verzögerungen bei der Replikation führen. Um die Verzögerung bei Replikaten 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 an stark frequentierten Tischen einen manuellen Vakuumfrostvorgang, bevor Sie die blaue/grüne Bereitstellung erstellen. Eine Anleitung dazu finden Sie unter Manuelles Einfrieren per Vakuum durchführen.

    • Deaktivieren Sie in SQL Postgre-Version 12 und höher den index_cleanup Parameter für große oder stark frequentierte Tabellen, um die Effizienz der regelmäßigen Wartung von Blue-Datenbanken zu verbessern. Weitere Informationen finden Sie unter Schnellstmögliches Löschen einer Tabelle.

      Anmerkung

      Wenn die Indexbereinigung während des Staubsaugens regelmäßig übersprungen wird, kann dies zu einer Aufblähung des Index führen, wodurch die Scanleistung beeinträchtigt werden kann. Es hat sich bewährt, diesen Ansatz nur zu verwenden, wenn Sie eine blaue/grüne Bereitstellung 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 Arbeitslast 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 Postgre SQL.

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

  • Überprüfen Sie die Leistung Ihrer DELETE AND-Anweisungen UPDATE und prüfen Sie, ob die Erstellung eines Indexes für die in der WHERE Klausel verwendete Spalte diese Abfragen optimieren kann. Dies kann die Leistung verbessern, wenn die Operationen in einer grünen Umgebung wiedergegeben 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, und pg_catalog.pg_replication_slots Objektenpg_catalog.pg_publication, deren Namen mit 'rds' beginnenpg_catalog.pg_subscription, 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.