Einschränkungen und Überlegungen für Aurora blue/green Aurora-Bereitstellungen - Amazon Aurora
EinschränkungenÜberlegungen

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.

Einschränkungen und Überlegungen für Aurora blue/green Aurora-Bereitstellungen

Blaue/grüne Bereitstellungen in Amazon RDS erfordern eine sorgfältige Abwägung von Faktoren wie Replikationssteckplätzen, Ressourcenmanagement, Instance-Größe und potenziellen Auswirkungen auf die Datenbankleistung. Die folgenden Abschnitte enthalten Anleitungen zur Optimierung Ihrer Bereitstellungsstrategie, um minimale Ausfallzeiten, reibungslose Übergänge und eine effektive Verwaltung Ihrer Datenbankumgebung sicherzustellen.

Einschränkungen für blue/green Bereitstellungen

Die folgenden Einschränkungen gelten für blue/green Bereitstellungen.

Allgemeine Einschränkungen für Blau/Grün-Bereitstellungen

Die folgenden allgemeinen Einschränkungen gelten für blue/green Bereitstellungen:

  • Sie können einen Cluster, der Teil einer blue/green Bereitstellung ist, nicht beenden und starten.

  • Blaue/grüne Bereitstellungen unterstützen nicht die Verwaltung von Masterbenutzerkennwörtern mit. AWS Secrets Manager

  • Wenn Sie versuchen, einen Backtrack auf dem blauen DB-Cluster zu erzwingen, wird die blue/green Bereitstellung unterbrochen und der Switchover wird blockiert.

  • Während der Umstellung sind für die blauen und grünen Umgebungen keine Null-ETL-Integrationen mit Amazon Redshift möglich. Sie müssen zuerst die Integration löschen und umstellen. Anschließend erstellen Sie die Integration neu.

  • Der Event Scheduler (event_schedulerParameter) muss in der grünen Umgebung deaktiviert sein, wenn Sie eine Bereitstellung erstellen. blue/green Dadurch wird verhindert, dass Ereignisse in der grünen Umgebung generiert werden und zu Inkonsistenzen führen.

  • Auto Scaling Scaling-Richtlinien, die auf dem blauen DB-Cluster konfiguriert sind, werden nicht in die grüne Umgebung kopiert. Sie müssen sie nach dem Switchover neu konfigurieren, unabhängig davon, ob sie ursprünglich in der blauen oder grünen Umgebung eingerichtet wurden.

  • Sie können einen unverschlüsselten DB-Cluster nicht in einen verschlüsselten DB-Cluster ändern.

  • Sie können einen blauen nicht in eine höhere Engine-Version als den entsprechenden grünen ändern.

  • Die Ressourcen in der blauen und der grünen Umgebung müssen sich in demselben AWS-Konto befinden.

  • Blau/Grün-Bereitstellungen werden für die folgenden Funktionen nicht unterstützt:

    • Amazon-RDS-Proxy

    • Regionsübergreifende Lesereplikate

    • Aurora Serverless v1-DB-Cluster

    • DB-Cluster, die Teil einer globalen Aurora-Datenbank sind

    • AWS CloudFormation

Einschränkungen von Aurora MySQL für blue/green Bereitstellungen

Die folgenden Einschränkungen gelten für blue/green Bereitstellungen von Aurora MySQL :

  • Der Quell-DB-Cluster darf keine benannten tmp Datenbanken enthalten. Datenbanken mit diesem Namen werden nicht in die grüne Umgebung kopiert.

  • Der blaue kann kein externes Binlog-Replikat sein.

  • Wenn für den Quell-DB-Cluster Backtrack aktiviert ist, wird der grüne DB-Cluster ohne Backtracking-Unterstützung erstellt. Das liegt daran, dass Backtracking bei der Replikation von Binärprotokollen (Binlog), die für Bereitstellungen erforderlich ist, nicht funktioniert. blue/green Weitere Informationen finden Sie unter Rückverfolgen eines Aurora-DB-Clusters.

  • Blaue/grüne Bereitstellungen unterstützen den AWS JDBC-Treiber für MySQL nicht. Weitere Informationen finden Sie unter Bekannte Einschränkungen von. GitHub

  • Nicht protokollierte Tabellen werden nicht in die grüne Umgebung repliziert, es sei denn, der rds.logically_replicate_unlogged_tables Parameter ist 1 auf dem blauen DB-Cluster auf eingestellt. Ändern Sie diesen Parameterwert nicht, nachdem Sie eine blue/green Bereitstellung erstellt haben, um mögliche Replikationsfehler bei Tabellen ohne Protokollierung zu vermeiden.

  • Der blaue kann keine logische Quelle (Herausgeber) oder Replikat (Abonnent) sein.

  • Wenn der blaue DB-Cluster als fremder Server einer FDW-Erweiterung (Foreign Data Wrapper) konfiguriert ist, müssen Sie den Endpunktnamen des -Clusters anstelle von IP-Adressen verwenden. Dadurch kann die Konfiguration auch nach der Umstellung funktionsfähig bleiben.

  • In einer blue/green Bereitstellung benötigt jede Datenbank einen logischen Replikationssteckplatz. Mit zunehmender Anzahl von Datenbanken nimmt der Ressourcenaufwand zu, was möglicherweise zu Verzögerungen bei der Replikation führen kann, insbesondere wenn die nicht ausreichend skaliert ist. Die Auswirkungen hängen von Faktoren wie der Datenbankauslastung und der Anzahl der Verbindungen ab. Um dies zu minimieren, sollten Sie erwägen, Ihre DB-Instance-Klasse zu skalieren oder die Anzahl der Datenbanken auf der zu reduzieren.

  • Blaue/grüne Bereitstellungen werden für Babelfish for Aurora PostgreSQL nur für Version 15.7 und höher (15) und 16.3 und höher (16) unterstützt.

  • Wenn Sie Ausführungspläne in Aurora Replicas erfassen möchten, müssen Sie beim Aufrufen der apg_plan_mgmt.create_replica_plan_capture-Funktion den Endpunkt des blauen DB-Clusters angeben. Dadurch wird sichergestellt, dass die Planerfassungen nach der Umstellung weiterhin funktionieren. Weitere Informationen finden Sie unter Erfassung von Aurora-PostgreSQL-Ausführungsplänen.

  • Der Prozess zum Anwenden der logischen Replikation in der grünen Umgebung erfolgt über einen einzigen Thread. Wenn die blaue Umgebung ein hohes Volumen an Schreibverkehr generiert, kann die grüne Umgebung möglicherweise nicht Schritt halten. Dies kann zu Verzögerungen oder Fehlern bei der Replikation führen, insbesondere bei Workloads, die einen kontinuierlich hohen Schreibdurchsatz erzeugen. Stellen Sie sicher, dass Sie Ihre Workloads gründlich testen. Für Szenarien, die größere Versionsupgrades und die Verarbeitung umfangreicher Schreib-Workloads erfordern, sollten Sie alternative Ansätze wie die Verwendung von AWS Database Migration Service (AWS DMS) oder selbstverwalteter logischer Replikation in Betracht ziehen.

  • Das Erstellen neuer Partitionen in partitionierten Tabellen wird bei Blue/Green-Bereitstellungen für Aurora for PostgreSQL nicht unterstützt. Das Erstellen neuer Partitionen beinhaltet z. B. DDL-Operationen (Data Definition Language)CREATE TABLE, die nicht von der blauen Umgebung in die grüne Umgebung repliziert werden. Bestehende partitionierte Tabellen und ihre Daten werden jedoch in die grüne Umgebung repliziert.

  • Die folgenden Einschränkungen gelten für PostgreSQL-Erweiterungen:

    • Die pg_partman Erweiterung muss in der blauen Umgebung deaktiviert werden, wenn Sie eine blue/green Bereitstellung erstellen. Die Erweiterung führt DDL-Operationen wie etwa CREATE TABLE durch, die die logische Replikation von der blauen in die grüne Umgebung unterbrechen.

    • Die pg_cron Erweiterung muss nach der Erstellung der blue/green Bereitstellung in allen grünen Datenbanken deaktiviert bleiben. Die Erweiterung verfügt über Hintergrund-Worker, die als Superuser ausgeführt werden und die Schreibschutzeinstellung der grünen Umgebung umgehen, was zu Replikationskonflikten führen kann.

    • Für die apg_plan_mgmt-Erweiterung muss der apg_plan_mgmt.capture_plan_baselines-Parameter für alle grünen Datenbanken auf off gesetzt sein, um Primärschlüsselkonflikte zu vermeiden, wenn ein identischer Plan in der blauen Umgebung erfasst wird. Weitere Informationen finden Sie unter Übersicht über die Abfrageplanverwaltung in Aurora PostgreSQL.

    • Die pgactive Erweiterungen pglogical und müssen in der blauen Umgebung deaktiviert sein, wenn Sie eine blue/green Bereitstellung erstellen. Nachdem Sie die grüne Umgebung zur neuen Produktionsumgebung umgestellt haben, können Sie die Erweiterungen wieder aktivieren. Dazu kann die blaue Datenbank kein logischer Subscriber einer externen Instance sein.

    • Wenn Sie die pgAudit Erweiterung verwenden, muss sie in den gemeinsam genutzten Bibliotheken (shared_preload_libraries) der benutzerdefinierten DB-Parametergruppen sowohl für die blaue als auch für die grüne DB-Instance verbleiben. Weitere Informationen finden Sie unter Einrichtung der pgAudit Erweiterung.

Spezifische Einschränkungen der logischen Replikation für Bereitstellungen blue/green

PostgreSQL hat bestimmte Einschränkungen in Bezug auf die logische Replikation, die sich in Einschränkungen bei der Erstellung von blue/green Bereitstellungen für Aurora PostgreSQL-DB-Cluster, für PostgreSQL-DB-Instances niederschlagen.

In der folgenden Tabelle werden die Einschränkungen der logischen Replikation beschrieben, die für Blau/Grün-Bereitstellungen für Aurora PostgreSQL gelten. Weitere Informationen finden Sie in der Dokumentation zur logischen Replikation in PostgreSQL.

Einschränkung Erklärung
Data Definition Language (DDL)-Anweisungen wie CREATE TABLE und CREATE SCHEMA werden nicht von der blauen in die grüne Umgebung repliziert.

Wenn Aurora eine DDL-Änderung in der blauen Umgebung erkennt, gehen die grünen Datenbanken in den Status Replikation herabgestuft über. Sie müssen die blue/green Bereitstellung und alle grünen Datenbanken löschen und sie dann neu erstellen.
DCL-Anweisungen (Data Control Language), wie z. B. GRANT undREVOKE, werden nicht von der blauen Umgebung in die grüne Umgebung repliziert.

Wenn Aurora einen Versuch erkennt, eine DCL-Anweisung in der blauen Umgebung auszuführen, wird eine Warnmeldung angezeigt. Es ist keine Konfiguration oder API verfügbar, um dieses Verhalten zu ändern, da dies eine Einschränkung des blue/green Bereitstellungsprozesses darstellt.
NEXTVAL-Operationen an Sequenzobjekten werden nicht zwischen der blauen und der grünen Umgebung synchronisiert.

Während der Umstellung erhöht Aurora die Sequenzwerte in der grünen Umgebung so, dass sie denen in der blauen Umgebung entsprechen. Wenn Sie Tausende von Sequenzen haben, kann dies die Umstellung verzögern.
Große Objekte in der blauen Umgebung werden nicht in die grüne Umgebung repliziert. Dazu gehören sowohl vorhandene große Objekte als auch alle während des blue/green Bereitstellungsprozesses neu erstellten oder geänderten großen Objekte.

Wenn Aurora die Erstellung oder Änderung großer Objekte in der blauen Umgebung erkennt, die in der pg_largeobject-Systemtabelle gespeichert sind, gehen die grünen Datenbanken in den Status Replikation herabgestuft über. Sie müssen die blue/green Bereitstellung und alle grünen Datenbanken löschen und sie dann neu erstellen.

Durch das Aktualisieren materialisierter Ansichten wird die Replikation unterbrochen.

Durch das Aktualisieren materialisierter Ansichten in der blauen Umgebung wird die Replikation in die grüne Umgebung unterbrochen. Vermeiden Sie es, materialisierte Ansichten in der blauen Umgebung zu aktualisieren. Nach einem Switchover können Sie sie manuell mit dem Befehl REFRESH MATERIALIZED VIEW aktualisieren oder eine Aktualisierung planen.

UPDATE- und DELETE-Operationen sind für Tabellen, die keinen Primärschlüssel haben, nicht zulässig.

Bevor Sie ein blue/green Deployment erstellen, stellen Sie sicher, dass alle Tabellen über einen Primärschlüssel oder eine Verwendung verfügen. REPLICA IDENTITY FULL Verwenden Sie diese Option jedoch nur, REPLICA IDENTITY FULL wenn kein primärer oder eindeutiger Schlüssel vorhanden ist, da dies die Replikationsleistung beeinträchtigt. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation.

Überlegungen zu blue/green Bereitstellungen

Amazon RDS verfolgt Ressourcen in blue/green Bereitstellungen mit dem DbiResourceId und DbClusterResourceId jeder Ressource. Diese Ressourcen-ID ist eine AWS-Region eindeutige, unveränderliche Kennung für die Ressource.

Die Ressourcen-ID ist von der des DB-Clusters getrennt. Jede einzelne ist in der Datenbankkonfiguration in der RDS-Konsole aufgeführt.

Der Name (Cluster-ID) einer Ressource ändert sich, wenn Sie zu einer blue/green Bereitstellung wechseln, aber jede Ressource behält dieselbe Ressourcen-ID. Eine DB-Cluster-ID in der blauen Umgebung lautete beispielsweise mycluster. Nach der Umstellung könnte dieser DB-Cluster in mycluster-old1 umbenannt sein. Die Ressourcen-ID des DB-Clusters ändert sich während der Umstellung jedoch nicht. Wenn Sie also die grünen Ressourcen auf die neuen Produktionsressourcen umstellen, stimmen ihre Ressourcen IDs nicht mit den blauen Ressourcen überein IDs , die zuvor in Produktion waren.

Nachdem Sie eine blue/green Bereitstellung umgestellt haben, sollten Sie erwägen, die Ressource IDs auf die Ressourcen der neu umgestellten Produktionsressourcen für integrierte Funktionen und Dienste zu aktualisieren, die Sie mit den Produktionsressourcen verwendet haben. Berücksichtigen Sie insbesondere die folgenden Aktualisierungen:

  • Wenn Sie die Filterung mithilfe der RDS-API und der RDS-Ressource durchführen IDs, passen Sie die für die Filterung IDs verwendete Ressource nach dem Switchover an.

  • Wenn Sie Ressourcen CloudTrail für die Überwachung verwenden, passen Sie die Benutzer von so an, CloudTrail dass sie die neue Ressource IDs nach dem Switchover verfolgen. Weitere Informationen finden Sie unter Amazon Aurora überwachen API ruft an AWS CloudTrail.

  • Wenn Sie Datenbank-Aktivitätsstreams für Ressourcen in der blauen Umgebung verwenden, passen Sie Ihre Anwendung an, um die Datenbankereignisse für den neuen Stream nach der Umstellung zu überwachen. Weitere Informationen finden Sie unter Unterstützte Regionen und Aurora-DB-Engines für Datenbankaktivitätsstreams.

  • Wenn Sie die Performance Insights Insights-API verwenden, passen Sie die Ressource IDs in API-Aufrufen nach dem Switchover an. Weitere Informationen finden Sie unter Überwachung mit Performance Insights auf .

    Sie können eine Datenbank mit demselben Namen nach der Umstellung überwachen, diese enthält jedoch nicht die Daten, die vor der Umstellung vorhanden waren.

  • Wenn Sie Ressourcen IDs in IAM-Richtlinien verwenden, stellen Sie sicher, dass Sie bei Bedarf die Ressource IDs der neu übertragenen Ressourcen hinzufügen. Weitere Informationen finden Sie unter Identitäts- und Zugriffsmanagement für Amazon Aurora.

  • Wenn Ihrer IAM-Rollen zugeordnet sind, stellen Sie sicher, dass Sie diese nach dem Switchover erneut zuordnen. Angehängte Rollen werden nicht automatisch in die grüne Umgebung kopiert.

  • Wenn Sie sich mithilfe der IAM-Datenbankauthentifizierung bei Ihrem DB-Cluster authentifizieren, stellen Sie sicher, dass in der für den Datenbankzugriff verwendeten IAM-Richtlinie sowohl die blauen als auch die grünen Datenbanken unter dem Element Resource der Richtlinie aufgeführt sind. Dies ist erforderlich, um nach der Umstellung eine Verbindung mit der grünen Datenbank herzustellen. Weitere Informationen finden Sie unter Erstellen und Verwenden einer IAM-Richtlinie für den IAM-Datenbankzugriff.

  • Wenn Sie einen manuellen DB-Cluster-Snapshot für einen DB-Cluster wiederherstellen möchten, der Teil einer blue/green Bereitstellung war, stellen Sie sicher, dass Sie den richtigen DB-Cluster-Snapshot wiederherstellen, indem Sie den Zeitpunkt überprüfen, zu dem der Snapshot erstellt wurde. Weitere Informationen finden Sie unter Wiederherstellen aus einem DB-Cluster-Snapshot.

  • Nach dem Umschalten AWS Database Migration Service (AWS DMS) können die Replikationsaufgaben nicht fortgesetzt werden, da der Checkpoint aus der blauen Umgebung in der grünen Umgebung ungültig ist. Sie müssen die DMS-Aufgabe mit einem neuen Checkpoint neu erstellen, um die Replikation fortzusetzen.

  • Amazon Aurora erstellt die Grün-Umgebung, indem das zugrunde liegende Aurora-Speichervolume in der Blau-Umgebung geklont wird. Das grüne Cluster-Volume speichert nur inkrementelle Änderungen, die in der Grün-Umgebung vorgenommen wurden. Wenn Sie den DB-Cluster in der Blau-Umgebung löschen, wächst die Größe des zugrunde liegenden Aurora-Speichervolumens in der Grün-Umgebung auf die volle Größe an. Weitere Informationen finden Sie unter Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster.

  • Wenn Sie dem DB-Cluster in der grünen Umgebung einer Blau/Grün-Bereitstellung eine DB-Instance hinzufügen, ersetzt die neue DB-Instance bei der Umstellung keine DB-Instance in der blauen Umgebung. Die neue DB-Instance wird jedoch im DB-Cluster beibehalten und wird in der neuen Produktionsumgebung zu einer DB-Instance.

  • Wenn Sie eine DB-Instance im DB-Cluster in der grünen Umgebung einer blue/green deployment, you can't create a new DB instance to replace it in the blue/green Bereitstellung löschen.

    Wenn Sie eine neue DB-Instance mit demselben Namen und ARN wie die gelöschte DB-Instance erstellen, hat sie eine andere DbiResourceId. Sie ist folglich nicht Teil der grünen Umgebung.

    Das folgende Verhalten ergibt sich, wenn Sie eine DB-Instance im DB-Cluster der grünen Umgebung löschen:

    • Wenn die DB-Instance in der blauen Umgebung mit dem gleichen Namen vorhanden ist, wird sie nicht auf die DB-Instance in der grünen Umgebung umgestellt. Diese DB-Instance wird nicht umbenannt, indem dem DB-Instance-Namen -oldn angefügt wird.

    • Jede Anwendung, die auf die DB-Instance in der blauen Umgebung verweist, verwendet nach der Umstellung weiterhin dieselbe DB-Instance.