Übersicht über Blau/Grün-Bereitstellungen von Amazon RDS - Amazon Relational Database Service
Verfügbarkeit von Regionen und VersionenVorteileWorkflowAutorisieren des ZugriffsÜberlegungenBewährte MethodenEinschränkungen

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.

Übersicht über Blau/Grün-Bereitstellungen von Amazon RDS

Mithilfe von Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbankänderungen vornehmen und testen, bevor Sie sie in einer Produktionsumgebung implementieren. Mit einer Blau/Grün-Bereitstellung wird eine Staging-Umgebung erstellt, die die Produktionsumgebung kopiert. In einer Blau/Grün-Umgebung ist die blaue Umgebung die aktuelle Produktionsumgebung. Die grüne Umgebung ist die Staging-Umgebung. Die Staging-Umgebung bleibt mithilfe der logischen Replikation mit der aktuellen Produktionsumgebung synchronisiert.

Sie können Änderungen an den RDS-DB-Instances in der grünen Umgebung vornehmen, ohne die Produktions-Workloads zu beeinträchtigen. Sie können beispielsweise die Haupt- oder Nebenversion der DB-Engine aktualisieren, die zugrundeliegende Dateisystemkonfiguration aktualisieren oder Datenbankparameter in der Staging-Umgebung ändern. Sie können Änderungen in der grünen Umgebung gründlich testen. Wenn Sie bereit sind, können Sie die Umgebungen umstellen, um die grüne Umgebung zur neuen Produktionsumgebung hochzustufen. Die Umstellung dauert in der Regel weniger als eine Minute, ohne dass Daten verloren gehen und Anwendungsänderungen erforderlich sind.

Da die grüne Umgebung eine Kopie der Topologie der Produktionsumgebung ist, umfasst die grüne Umgebung die von der DB-Instance verwendeten Funktionen. Zu diesen Funktionen gehören die Lesereplikate, die Speicherkonfiguration, DB-Snapshots, automatische Backups, Performance Insights und die verbesserte Überwachung. Wenn es sich bei der blauen DB-Instance um eine Multi-AZ-Bereitstellung handelt, entspricht die grüne DB-Instance ebenfalls einer Multi-AZ-Bereitstellung.

Anmerkung

Derzeit werden Blau/Grün-Bereitstellungen nur für RDS für MariaDB, RDS für MySQL und RDS für PostgreSQL unterstützt. Informationen zur Verfügbarkeit von Amazon Aurora finden Sie unter Verwenden von Amazon RDS Blue/Green Deployments für Datenbank-Updates im Amazon Aurora Aurora-Benutzerhandbuch.

Verfügbarkeit von Regionen und Versionen

Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen finden Sie unter Unterstützte Regionen und DB-Engines für Amazon RDS Blue/Green-Bereitstellungen.

Vorteile der Verwendung von Blau/Grün-Bereitstellung von Amazon RDS

Durch die Verwendung von Blau/Grün-Bereitstellungen von Amazon RDS können Sie über Sicherheitspatches auf dem Laufenden bleiben, die Datenbankleistung verbessern und neuere Datenbankfunktionen mit kurzen, vorhersehbaren Ausfallzeiten einführen. Blau/Grün-Bereitstellungen reduzieren die Risiken und Ausfallzeiten für Datenbankaktualisierungen, wie Upgrades von Engine-Haupt- und -Nebenversionen.

Blau/Grün-Bereitstellungen bieten die folgenden Vorteile:

  • Sie können ganz einfach eine produktionsreife Staging-Umgebung erstellen.

  • Sie können Datenbankänderungen von der Produktionsumgebung in die Staging-Umgebung automatisch replizieren.

  • Sie können Datenbankänderungen in einer sicheren Staging-Umgebung testen, ohne die Produktionsumgebung zu beeinträchtigen.

  • Sie bleiben mit Datenbank-Patches und Systemaktualisierungen auf dem Laufenden.

  • Sie können neue Datenbankfunktionen implementieren und testen.

  • Sie können Ihre Staging-Umgebung auf die neue Produktionsumgebung umstellen, ohne Änderungen an Ihrer Anwendung vorzunehmen.

  • Die Umstellung erfolgt durch den Einsatz des integrierten Integritätsschutzes völlig sicher.

  • Es treten keine Datenverluste während der Umstellung auf.

  • Die Umstellung erfolgt schnell, in der Regel in weniger als einer Minute, abhängig von Ihrer Workload.

Workflow einer Blau/Grün-Bereitstellung

Führen Sie die folgenden Hauptschritte aus, wenn Sie eine Blau/Grün-Bereitstellung für Datenbankaktualisierungen verwenden.

  1. Identifizieren Sie eine Produktionsumgebung, die aktualisiert werden muss.

    Die Produktionsumgebung in dieser Abbildung verfügt beispielsweise über eine Multi-AZ-Bereitstellung der DB-Instance (mydb1) und ein Lesereplikat (mydb2).

    Produktionsumgebung (blau) in einer Blau/Grün-Bereitstellung

  2. Erstellen Sie die Blau/Grün-Bereitstellung. Anweisungen finden Sie unter Erstellen einer Blau/Grün-Bereitstellung.

    Die folgende Abbildung zeigt ein Beispiel für eine Blau/Grün-Bereitstellung der Produktionsumgebung aus Schritt 1. Bei der Erstellung der Blau/Grün-Bereitstellung kopiert RDS die vollständige Topologie und Konfiguration der primären DB-Instance, um die grüne Umgebung zu erstellen. Den kopierten DB-Instance-Namen wird -green-random-characters angehängt. Die Staging-Umgebung in der Abbildung enthält eine Multi-AZ-Bereitstellung der DB-Instance (mydb1-green-abc123) und ein Lesereplikat (mydb2-green-abc123).

    Blau/Grün-Bereitstellung

    Wenn Sie die Blau/Grün-Deployment erstellen, können Sie Ihre DB-Engine-Version aktualisieren und eine andere DB-Parametergruppe für die DB-Instances in der grünen Umgebung angeben. RDS konfiguriert auch die logische Replikation von der primären DB-Instance in der blauen Umgebung zur primären DB-Instance in der grünen Umgebung.

    Nachdem Sie die Blau/Grün-Bereitstellung erstellt haben, ist die DB-Instance in der grünen Umgebung standardmäßig schreibgeschützt.

  3. Nehmen Sie bei Bedarf weitere Änderungen an der Staging-Umgebung vor.

    Sie können beispielsweise Schemaänderungen an Ihrer Datenbank vornehmen oder die DB-Instance-Klasse ändern, die von einer oder mehreren DB-Instances in der grünen Umgebung verwendet wird.

    Informationen zum Ändern einer DB-Instance finden Sie unter Ändern einer Amazon RDS-DB-Instance.

  4. Testen Sie Ihre Staging-Umgebung.

    Während des Testens empfehlen wir, dass Sie Ihre Datenbanken in der grünen Umgebung schreibgeschützt lassen. Aktivieren Sie Schreibvorgänge in der grünen Umgebung mit Vorsicht, da sie zu Replikationskonflikten führen können. Sie können auch zu ungewollten Daten in den Produktionsdatenbanken nach der Umstellung führen. Um Schreibvorgänge für RDS for MySQL zu aktivieren, setzen Sie den read_only Parameter auf 0 und starten Sie dann die DB-Instance neu. Für RDS for PostgreSQL setzen Sie den default_transaction_read_only Parameter auf off Sitzungsebene auf.

  5. Wenn Sie bereit sind, können Sie die Umstellung vornehmen und die Staging-Umgebung zur neuen Produktionsumgebung hochstufen. Anweisungen finden Sie unter Umstellen einer Blau/Grün-Bereitstellung.

    Die Umstellung führt zu Ausfallzeiten. Die Ausfallzeit beträgt normalerweise weniger als eine Minute, kann aber je nach Workload länger sein.

    Die folgende Abbildung zeigt die DB-Instances nach der Umstellung.

    DB-Instances nach der Umstellung einer Blau/Grün-Bereitstellung

    Nach der Umstellung werden die DB-Instances, die sich in der grünen Umgebung befanden, zu den neuen Produktions-DB-Instances. Die Namen und Endpunkte in der aktuellen Produktionsumgebung werden der neu hochgestuften Produktionsumgebung zugewiesen, sodass keine Änderungen an Ihrer Anwendung erforderlich sind. Infolgedessen fließt Ihr Produktionsdatenverkehr jetzt in die neue Produktionsumgebung. Die DB-Instances in der vorherigen blauen Umgebung werden umbenannt, indem -oldn an den aktuellen Namen angehängt wird, wobei n eine Zahl ist. Angenommen, der Name der DB-Instance in der blauen Umgebung lautet mydb1. Nach der Umstellung könnte der Name der DB-Instance mydb1-old1 lauten.

    In dem Beispiel in der Abbildung werden bei der Umstellung die folgenden Änderungen vorgenommen:

    • Die Multi-AZ-Bereitstellung der DB-Instance in der grünen Umgebung mit dem Namen mydb1-green-abc123 wird zur Produktions-Multi-AZ-Bereitstellung der DB-Instance und trägt nun den Namen mydb1.

    • Das Lesereplikat der grünen Umgebung namens mydb2-green-abc123 wird zum Produktionslesereplikat mydb2.

    • Die Multi-AZ-Bereitstellung der DB-Instance in der blauen Umgebung namens mydb1 wird in mydb1-old1 umbenannt.

    • Das Lesereplikat der blauen Umgebung mit dem Namen mydb2 wird in mydb2-old1 umbenannt.

  6. Eine Blau/Grün-Bereitstellung, die Sie nicht mehr benötigen, können Sie löschen. Anweisungen finden Sie unter Löschen einer Blau/Grün-Bereitstellung.

    Nach der Umstellung wird die vorherige Produktionsumgebung nicht gelöscht, sodass Sie sie bei Bedarf für Regressionstests verwenden können.

Autorisierung des Zugangs zu Operationen in der Blau/Grün-Bereitstellung

Benutzer müssen über die erforderlichen Berechtigungen verfügen, um Operationen im Zusammenhang mit Blau/Grün-Bereitstellungen ausführen zu können. Sie können IAM-Richtlinien erstellen, die Benutzern und Rollen die Berechtigung zum Ausführen bestimmter API-Operationen für die angegebenen Ressourcen gewähren, die diese benötigen. Sie können diese Richtlinien dann den IAM-Berechtigungssätzen oder -Rollen zuordnen, die diese Berechtigungen benötigen. Weitere Informationen finden Sie unter Identity and Access Management für Amazon RDS.

Der Benutzer, der eine Blau/Grün-Bereitstellung erstellt, muss über Berechtigungen zum Ausführen folgender RDS-Operationen verfügen:

  • rds:AddTagsToResource

  • rds:CreateDBInstanceReadReplica

Der Benutzer, der eine Blau/Grün-Bereitstellung umstellt, muss über Berechtigungen zum Ausführen folgender RDS-Operationen verfügen:

  • rds:ModifyDBInstance

  • rds:PromoteReadReplica

Der Benutzer, der eine Blau/Grün-Bereitstellung löscht, muss über Berechtigungen zum Ausführen folgender RDS-Operation verfügen:

  • rds:DeleteDBInstance

Amazon RDS stellt in Ihrem Namen Ressourcen in der Staging-Umgebung bereit und ändert sie. Zu diesen Ressourcen gehören DB-Instances, die eine intern definierte Namenskonvention verwenden. Daher dürfen angehängte IAM-Richtlinien keine unvollständigen Muster für Ressourcennamen enthalten, wie my-db-prefix-* z. Nur Platzhalter (*) werden unterstützt. Im Allgemeinen empfehlen wir, Ressourcen-Tags und andere unterstützte Attribute anstelle von Platzhaltern zu verwenden, um den Zugriff auf diese Ressourcen zu steuern. Weitere Informationen finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für Amazon RDS.

Überlegungen zur Blau/Grün-Bereitstellungen

Amazon RDS verfolgt Ressourcen in Blau/Grün-Bereitstellungen mit der DbiResourceId jeder Ressource. Diese Ressourcen-ID ist eine AWS-Region eindeutige, unveränderliche Kennung für die Ressource.

Die Ressourcen-ID ist getrennt von der DB-Instance-ID:

Blau/Grün-Bereitstellung erstellen

Der Name (Instance-ID) einer Ressource ändert sich, wenn Sie auf eine Blau/Grün-Bereitstellung umstellen, jede Ressource behält jedoch dieselbe Ressourcen-ID. Eine DB-Instance-ID in der blauen Umgebung könnte beispielsweise mydb lauten. Nach der Umstellung könnte diese DB-Instance in mydb-old1 umbenannt sein. Die Ressourcen-ID der DB-Instance ändert sich während der Umstellung jedoch nicht. Wenn also die grünen Ressourcen auf die neuen Produktionsressourcen hochgestuft werden, stimmen ihre Ressourcen-IDs nicht mit den blauen Ressourcen-IDs überein, die zuvor in der Produktion vorhanden waren.

Nach der Umstellung auf eine Blau/Grün-Bereitstellung sollten Sie erwägen, die Ressourcen-IDs auf die IDs der neu hochgestuften 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 Ressourcen-IDs durchführen, passen Sie die beim Filtern verwendeten Ressourcen-IDs nach der Umstellung an.

  • Wenn Sie Ressourcen CloudTrail für die Überwachung verwenden, passen Sie die Benutzer von so an, CloudTrail dass sie die neuen Ressourcen-IDs nach dem Switchover verfolgen. Weitere Informationen finden Sie unter Überwachung von Amazon RDS-API-Aufrufen in AWS CloudTrail.

  • Wenn Sie die Performance-Insights-API verwenden, passen Sie die Ressourcen-IDs in API-Aufrufen nach der Umstellung an. Weitere Informationen finden Sie unter Überwachung mit Performance Insights auf Amazon RDS.

    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 in IAM-Richtlinien Ressourcen-IDs verwenden, stellen Sie sicher, dass Sie bei Bedarf die Ressourcen-IDs der neu hochgestuften Ressourcen hinzufügen. Weitere Informationen finden Sie unter Identity and Access Management für Amazon RDS.

  • 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 Ihrer DB-Instance 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 AWS Backup automatische Backups von Ressourcen in einer blauen/grünen Bereitstellung verwalten, passen Sie die Ressourcen-IDs an, die AWS Backup nach dem Switchover verwendet werden. Weitere Informationen finden Sie unter Verwenden von AWS Backup zur Verwaltung automatisierter Backups.

  • Wenn Sie einen manuellen oder automatisierten DB-Snapshot für eine DB-Instance wiederherstellen möchten, die Teil einer Blau/Grün-Bereitstellung war, stellen Sie sicher, dass Sie den richtigen DB-Snapshot wiederherstellen, indem Sie den Zeitpunkt überprüfen, zu dem der Snapshot erstellt wurde. Weitere Informationen finden Sie unter Wiederherstellen aus einem DB--Snapshot.

  • Wenn Sie ein früheres automatisches Backup in einer blauen Umgebung beschreiben oder es zu einem bestimmten Zeitpunkt wiederherstellen möchten, verwenden Sie die Ressourcen-ID für die Operation.

    Da sich der Name der DB-Instance während der Umstellung ändert, können Sie ihren vorherigen Namen nicht für DescribeDBInstanceAutomatedBackups- oder RestoreDBInstanceToPointInTime-Operationen verwenden.

    Weitere Informationen finden Sie unter Wiederherstellen einer DB-Instance zu einer bestimmten Zeit.

  • Wenn Sie einer DB-Instance in der grünen Umgebung einer Blau/Grün-Bereitstellung ein Lesereplikat hinzufügen, ersetzt das neue Lesereplikat bei der Umstellung kein Lesereplikat in der blauen Umgebung. Das neue Lesereplikat wird jedoch nach der Umstellung in der neuen Produktionsumgebung beibehalten.

  • Wenn Sie eine DB-Instance in der grünen Umgebung einer Blau/Grün-Bereitstellung löschen, können Sie keine neue DB-Instance erstellen, um sie in der Blau/Grün-Bereitstellung zu ersetzen.

    Wenn Sie eine neue DB-Instance mit demselben Namen und Amazon-Ressourcennamen (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 in 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 hinzugefügt wird.

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

    Das gleiche Verhalten gilt für DB-Instances und Lesereplikate.

Bewährte Methoden für Blau/Grün-Bereitstellungen

Nachfolgend sind bewährte Methoden für Blau/Grün-Bereitstellungen aufgeführt:

Allgemeine bewährte Methoden

  • Testen Sie die DB-Instances 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 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.

  • Nachdem Sie die Blau/Grün-Bereitstellung erstellt haben, führen Sie gegebenenfalls Lazy Loading durch. Stellen Sie sicher, dass das Laden der Daten abgeschlossen ist, bevor Sie umstellen. Weitere Informationen finden Sie unter Umgang mit Lazy Loading beim Erstellen einer Grün/Blau-Bereitstellung.

  • 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.

Bewährte Methoden für RDS für MySQL

  • Vermeiden Sie die Verwendung von nicht-transaktionalen Speicher-Engines wie MyISAM, die nicht für die Replikation optimiert sind.

  • Optimieren Sie die Lesereplikate für die binäre Protokollreplikation.

    Wenn Ihre DB-Engine-Version dies beispielsweise unterstützt, sollten Sie die GTID-Replikation, die parallele Replikation und die absturzsichere Replikation in Ihrer Produktionsumgebung verwenden, bevor Sie Ihre Blau/Grün-Bereitstellung zur Verfügung stellen. Diese Optionen fördern die Konsistenz und Beständigkeit Ihrer Daten, bevor Sie Ihre Blau/Grün-Bereitstellung umstellen. Weitere Informationen über die GTID-Replikation für Lesereplikate finden Sie unter Verwenden der GTID-basierten Replikation.

Bewährte Methoden für RDS für PostgreSQL

  • Wenn Ihre Datenbank über ausreichend freien Speicher verfügt, 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. Sie können den freien Speicher mit der Metrik überwachen. FreeableMemory CloudWatch Weitere Informationen finden Sie unter CloudWatch Amazon-Instanzmetriken für Amazon RDS.

  • Aktualisieren Sie alle Ihre PostgreSQL-Erweiterungen auf die neueste Version, bevor Sie eine Blau/Grün-Bereitstellung erstellen. Weitere Informationen finden Sie unter Aktualisieren von PostgreSQL-Erweiterungen.

  • Wenn Sie die aws_s3-Erweiterung verwenden, stellen Sie sicher, dass Sie dem der grünen DB-Instance über eine IAM-Rolle Zugriff auf Amazon S3 gewähren, nachdem die grüne Umgebung erstellt wurde. Dadurch können die Import- und Exportbefehle auch nach der Umstellung weiter funktionieren. 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, die verzögert werden können, bis die grüne Umgebung die blaue Umgebung eingeholt hat.

    • Initiieren Sie an stark frequentierten Tischen einen manuellen Vakuum-Freeze-Vorgang, bevor Sie die blaue/grüne Bereitstellung erstellen.

    • Deaktivieren Sie für PostgreSQL Version 12 und höher den index_cleanup Parameter für große oder ausgelastete Tabellen, um die normale Wartungsrate bei blauen Datenbanken zu erhöhen. Weitere Informationen finden Sie unter Möglichst schnelles Bereinigen einer Tabelle.

  • 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.

  • Um zu verhindern, dass Write-Ahead-Log-Segmente (WAL) aus der blauen Umgebung entfernt werden, setzen Sie den wal_keep_segments Parameter für PostgreSQL Version 13 und niedriger auf 15625. Für Version 14 und höher setzen Sie den wal_keep_size Parameter auf 1 TiB, wenn genügend freier Speicherplatz vorhanden ist.

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

Die folgenden Einschränkungen gelten für Blau/Grün-Bereitstellungen:

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

Die folgenden Einschränkungen gelten für Blau/Grün-Bereitstellungen:

  • Die MySQL-Versionen 8.0.11 bis 8.0.13 haben einen Community-Bug, der RDS daran hindert, Blau/Grün-Bereitstellungen zu unterstützen.

  • Die folgenden Versionen von RDS für PostgreSQL werden als Upgrade-Quell- und Zielversionen unterstützt: 11.21 und höher, 12.16 und höher, 13.12 und höher, 14.9 und höher sowie 15.4 und höher. Für niedrigere Versionen können Sie ein Nebenversions-Upgrade auf eine unterstützte Version durchführen.

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

  • Wenn Dedicated Log Volume (DLV) in der blauen Datenbank aktiviert ist, muss es auf allen DB-Instances, einschließlich Read Replicas, aktiviert sein.

  • Für RDS für PostgreSQL werden nicht protokollierte Tabellen nicht in die grüne Umgebung repliziert, .

  • Für RDS for PostgreSQL kann der Blue Environment keine selbstverwaltete logische Quelle (Herausgeber) oder Replik (Abonnent) sein. Für RDS for MySQL kann der blaue kein externes Binlog-Replikat sein.

  • 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 Ereignisplaner (Parameter event_scheduler) muss in der grünen Umgebung deaktiviert werden, wenn Sie eine Blau/Grün-Bereitstellung erstellen. Dadurch wird verhindert, dass Ereignisse in der grünen Umgebung generiert werden und zu Inkonsistenzen führen.

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

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

    • Amazon-RDS-Proxy

    • Kaskadierende Lesereplikate

    • Regionsübergreifende Lesereplikate

    • AWS CloudFormation

    • Multi-AZ-DB-Cluster-Bereitstellungen

      Blau/Grün-Bereitstellungen werden für Multi-AZ-Bereitstellungen von DB-Instances unterstützt. Weitere Informationen zu Multi-AZ-Bereitstellungen finden Sie unter Konfiguration und Verwaltung einer Multi-AZ-Bereitstellung.

Einschränkungen der PostgreSQL-Erweiterung für Blue/Green-Bereitstellungen

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

  • Die pg_partman-Erweiterung muss in der blauen Umgebung deaktiviert werden, wenn Sie eine Blau/Grün-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 in allen grünen Datenbanken deaktiviert bleiben, nachdem die Blau/Grün-Bereitstellung erstellt wurde. 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.

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

  • Die Erweiterungen pglogical und pg_active müssen in der blauen Umgebung deaktiviert werden, wenn Sie eine Blau/Grün-Bereitstellung erstellen. Nachdem Sie die grüne Umgebung zur neuen Produktionsumgebung erklärt 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 Einrichten der pgAudit-Erweiterung.

Einschränkungen für Änderungen bei Blau/Grün-Bereitstellungen

Die folgenden Einschränkungen gelten für Änderungen in einer Blau/Grün-Bereitstellung:

  • Sie können eine unverschlüsselte DB-Instance nicht in eine verschlüsselte DB-Instance ändern.

  • Sie können eine verschlüsselte DB-Instance nicht in eine unverschlüsselte DB-Instance ändern.

  • Sie können eine DB-Instance in der blauen Umgebung nicht auf eine höhere Engine-Version als die der entsprechenden DB-Instance in der grünen Umgebung ändern.

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

  • Wenn die Quelldatenbank einer benutzerdefinierten Optionsgruppe zugeordnet ist, können Sie bei der Erstellung der Blau/Grün-Bereitstellung in RDS für MySQL kein Hauptversions-Upgrade angeben.

    In diesem Fall können Sie eine Blau/Grün-Bereitstellung erstellen, ohne ein Hauptversions-Upgrade anzugeben. Anschließend können Sie die Datenbank in der grünen Umgebung aktualisieren. Weitere Informationen finden Sie unter Upgrade der Engine-Version für eine DB-Instance.

Einschränkungen der logischen Replikation von PostgreSQL für Blau/Grün-Bereitstellungen

Blau/Grün-Bereitstellungen verwenden die logische Replikation, um die Staging-Umgebung mit der Produktionsumgebung synchron zu halten. PostgreSQL hat bestimmte Einschränkungen in Bezug auf die logische Replikation, die sich in Einschränkungen bei der Erstellung von Blau/Grün-Bereitstellungen für RDS-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 RDS für PostgreSQL gelten.

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 Amazon RDS eine DDL-Änderung in der blauen Umgebung erkennt, gehen die grünen Datenbanken in den Status Replikation herabgestuft über.

Sie erhalten ein Ereignis, das Sie darüber informiert, dass DDL-Änderungen in der blauen Umgebung nicht in die grüne Umgebung repliziert werden können. Sie müssen die Blau/Grün-Bereitstellung und alle grünen Datenbanken löschen und dann neu erstellen. Andernfalls können Sie die Blau/Grün-Bereitstellung nicht umstellen.
NEXTVAL-Operationen an Sequenzobjekten werden nicht zwischen der blauen und der grünen Umgebung synchronisiert.

Während der Umstellung erhöht Amazon RDS 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.
Die Erstellung oder Änderung großer Objekte in der blauen Umgebung wird nicht in die grüne Umgebung repliziert.

Wenn Amazon RDS 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.

RDS generiert ein Ereignis, das Sie darüber informiert, dass große Objektänderungen in der blauen Umgebung nicht in die grüne Umgebung repliziert werden können. Sie müssen die Blau/Grün-Bereitstellung und alle grünen Datenbanken löschen und dann neu erstellen. Andernfalls können Sie die Blau/Grün-Bereitstellung nicht umstellen.

Materialisierte Ansichten werden in der grünen Umgebung nicht automatisch aktualisiert.

Durch das Aktualisieren materialisierter Ansichten in der blauen Umgebung werden sie in der grünen Umgebung nicht aktualisiert. Nach der Umstellung können Sie eine Aktualisierung der materialisierten Ansichten planen.

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

Bevor Sie eine Blau/Grün-Bereitstellung erstellen, stellen Sie sicher, dass alle Tabellen in der DB-Instance über einen Primärschlüssel verfügen.

Weitere Informationen finden Sie in der Dokumentation zur logischen Replikation in PostgreSQL.