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 Amazon Aurora blue/green Bereitstellungen Blue/green Bereitstellungen in Amazon RDS erfordern eine sorgfältige Abwägung von Faktoren wie Replikationssteckplätzen, Ressourcenmanagement, Instance-Größe und möglichen Auswirkungen auf die Datenbankleistung. In den folgenden Abschnitten finden Sie Anleitungen zur Optimierung Ihrer Bereitstellungsstrategie, um minimale Ausfallzeiten, reibungslose Übergänge und eine effektive Verwaltung Ihrer Datenbankumgebung sicherzustellen. **Topics** + [Einschränkungen für Bereitstellungen blue/green](#blue-green-deployments-limitations) + [Beschränkungen der Aurora Global Database für blue/green Bereitstellungen](#blue-green-deployments-limitations-agd) + [Überlegungen zu Bereitstellungen blue/green](#blue-green-deployments-consider) ## Einschränkungen für Bereitstellungen blue/green Die folgenden Einschränkungen gelten für blue/green Bereitstellungen. **Topics** + [Allgemeine Einschränkungen für Bereitstellungen blue/green](#blue-green-deployments-limitations-general) + [Aurora MySQL Einschränkungen für Bereitstellungen blue/green](#blue-green-deployments-limitations-mysql) + [Aurora PostgreSQL Einschränkungen für Bereitstellungen blue/green](#blue-green-deployments-limitations-postgres-logical) ### Allgemeine Einschränkungen für Bereitstellungen blue/green 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. + Blue/green Bereitstellungen unterstützen nicht die Verwaltung von Hauptbenutzerkennwö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_scheduler`Parameter) muss in der grünen Umgebung deaktiviert werden, 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-Richtlinien, die im blauen DB-Cluster konfiguriert sind, werden nicht in die grüne Umgebung übernommen. Sie müssen sie nach der Umstellung 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. Zusätzlich können Sie einen verschlüsselten DB-Cluster nicht in einen unverschlüsselten DB-Cluster ändern. + Sie können einen blauen DB-Cluster nicht auf eine höhere Engine-Version als die des entsprechenden grünen DB-Clusters ändern. + Die Ressourcen in der blauen und der grünen Umgebung müssen sich in demselben AWS-Konto befinden. + Wenn Sie Amazon RDS Proxy verwenden, müssen Sie Ihren blauen Cluster beim Proxy registrieren, bevor Sie eine blue/green Bereitstellung erstellen. Wenn für einen bestimmten blauen Cluster bereits eine blue/green Bereitstellung existiert, wird die Registrierung dieses blauen Clusters bei Amazon RDS Proxy blockiert. + Amazon RDS Proxy mit blue/green Bereitstellungen wird für Aurora Global Databases nicht unterstützt. + Blue/green Bereitstellungen werden für die folgenden Funktionen nicht unterstützt: + Cross-Region Repliken lesen + Aurora Serverless v1-DB-Cluster + CloudFormation + Nach der Umstellung einer blue/green Bereitstellung wird der Verlauf der Point-in-Time-Wiederherstellung (PITR) nicht auf den neuen Produktions-DB-Cluster übertragen. Der grüne DB-Cluster behält seine eigene Ressourcen-ID. Der früheste wiederherstellbare Zeitpunkt beginnt, wenn Sie die grüne Umgebung erstellt haben. Sie können den neuen Produktions-DB-Cluster nicht zu einem früheren Zeitpunkt wiederherstellen, auch nicht zu einem Zeitpunkt vor dem Switchover. Der blaue DB-Cluster behält seinen eigenen PITR-Verlauf und automatische Backups, bis Sie ihn löschen. Um den blauen DB-Cluster nach dem Switchover wiederherzustellen, verwenden Sie seine Ressourcen-ID (`SourceDbClusterResourceId`), nicht seinen Namen. Der Name ändert sich während des Switchovers. Weitere Informationen finden Sie unter [Wiederherstellen eines DB-Clusters zu einer bestimmten Zeit](aurora-pitr.md). **Wichtig** Planen Sie diesen PITR-Reset ein, wenn Sie Anforderungen an die Aufbewahrung von Backups oder Recovery Point Objective (RPO) haben. Der neue Produktions-DB-Cluster kann keinen Recovery-Punkt aus der Zeit vor der Erstellung der grünen Umgebung erreichen, und sein PITR-Fenster erreicht den vollen Aufbewahrungszeitraum für Backups erst, wenn genügend Zeit verstrichen ist. Löschen Sie den blauen DB-Cluster nicht sofort, um die Möglichkeit zur Wiederherstellung auf einen Zeitpunkt vor dem Switchover beizubehalten. Lassen Sie den blauen DB-Cluster mindestens für die Dauer des erforderlichen Wiederherstellungsfensters laufen. Für einen beibehaltenen blauen DB-Cluster fallen weiterhin Gebühren für seine DB-Instances und seinen Speicher an, bis Sie ihn löschen. ### Aurora MySQL Einschränkungen für Bereitstellungen blue/green Die folgenden Einschränkungen gelten für Aurora MySQL blue/green MySQL-Bereitstellungen: + Der Quell-DB-Cluster kann keine Datenbanken mit dem Namen `tmp` enthalten. Datenbanken mit diesem Namen werden nicht in die grüne Umgebung kopiert. + Der blaue DB-Cluster kann kein externes Binlog-Replikat sein. + Wenn für den Quell-DB-Cluster die Rückverfolgung aktiviert ist, wird der grüne DB-Cluster ohne Unterstützung für die Rückverfolgung erstellt. Das liegt daran, dass Backtracking bei der Binärprotokollreplikation (Binärprotokoll), die für blue/green Bereitstellungen erforderlich ist, nicht funktioniert. Weitere Informationen finden Sie unter [Rückverfolgen eines Aurora-DB-Clusters](AuroraMySQL.Managing.Backtrack.md). + Blue/green Bereitstellungen unterstützen den AWS JDBC-Treiber für MySQL nicht. Weitere Informationen finden Sie unter [ Bekannte Einschränkungen von. ](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations) GitHub ### Aurora PostgreSQL Einschränkungen für Bereitstellungen blue/green Die folgenden Einschränkungen gelten für Aurora PostgreSQL blue/green PostgreSQL-Bereitstellungen + [Nicht protokollierte](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) Tabellen werden nicht in die grüne Umgebung repliziert, es sei denn, der Parameter `rds.logically_replicate_unlogged_tables` ist im blauen DB-Cluster auf `1` gesetzt. Ändern Sie diesen Parameterwert nicht, nachdem Sie eine blue/green Bereitstellung erstellt haben, um mögliche Replikationsfehler bei nicht protokollierten Tabellen zu vermeiden. + Bei dem blauen DB-Cluster kann es sich nicht um eine logische Quelle (Publisher) oder ein Replikat (Subscriber) handeln. + 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 Replikationsslot. Mit zunehmender Anzahl von Datenbanken nimmt der Ressourcenaufwand zu, was möglicherweise zu Verzögerungen bei der Replikation führen kann, insbesondere wenn der DB-Cluster nicht ausreichend skaliert ist. Die Auswirkungen hängen von Faktoren wie dem Datenbank-Workload und der Anzahl der Verbindungen ab. Um dies zu vermeiden, sollten Sie erwägen, Ihre DB-Instance-Klasse zu skalieren oder die Anzahl der Datenbanken im Quellcluster zu verringern. + Blue/green Bereitstellungen werden für Babelfish for Aurora PostgreSQL nur für Version 15.7 und höher (15 Versionen) 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](AuroraPostgreSQL.QPM.Plancapturereplicas.md). + Der [Prozess zum Anwenden](https://www.postgresql.org/docs/current/logical-replication-architecture.html) 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 Versions-Upgrades und die Verarbeitung umfangreicher Schreib-Workloads erfordern, sollten Sie alternative Ansätze in Betracht ziehen, wie die Verwendung von [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) oder [selbstverwalteter logischer Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html). + Das Erstellen neuer Partitionen auf partitionierten Tabellen wird bei blue/green Bereitstellungen für Aurora Das Erstellen neuer Partitionen umfasst Data Definition Language (DDL)-Operationen wie `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 Bereitstellung erstellen. blue/green 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](AuroraPostgreSQL.Optimize.overview.md). + Die `pgactive` Erweiterungen `pglogical` und müssen in der blauen Umgebung deaktiviert werden, 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 [Einrichten der pgAudit-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md). #### Logische replikationsspezifische Einschränkungen 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 (RDS) für PostgreSQL-DB-Instances niederschlagen. In der folgenden Tabelle werden die Einschränkungen der logischen Replikation beschrieben, die für blue/green Bereitstellungen für Aurora PostgreSQL RDS for PostgreSQL gelten. Weitere Informationen finden Sie in der [Dokumentation zur logischen Replikation in PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). | 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 das blue/green Deployment und alle grünen Datenbanken löschen und dann neu erstellen. | | Data Control Language (DCL)-Anweisungen wie GRANT und REVOKE werden nicht von der blauen 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. Bei einer großen Anzahl von Sequenzen kann der Switchover in der Regel durchgeführt werden, bei einer außergewöhnlich großen Anzahl von Sequenzen, z. B. mehreren hunderttausend, kann es jedoch zu einem Timeout kommen, bevor der Vorgang abgeschlossen ist. Sie können das Switchover-Timeout erhöhen, um mehr Zeit für die Synchronisation zu haben. Weitere Informationen finden Sie unter [Umstellungs-Timeout](blue-green-deployments-switching.md#blue-green-deployments-switching-timeout). | | Große Objekte in der blauen Umgebung werden nicht in die grüne Umgebung repliziert. Dies umfasst sowohl vorhandene große Objekte als auch alle neuen großen Objekte, die während des blue/green Bereitstellungsprozesses erstellt oder geändert wurden. | 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 das blue/green Deployment und alle grünen Datenbanken löschen und dann neu erstellen. | | Durch das Aktualisieren materialisierter Ansichten wird die Replikation unterbrochen. | Das Aktualisieren materialisierter Sichten in der blauen Umgebung unterbricht die Replikation in die grüne Umgebung. Vermeiden Sie das Aktualisieren materialisierter Ansichten in der blauen Umgebung. Nach einer Umstellung können Sie sie manuell mit dem Befehl [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) aktualisieren oder eine Aktualisierung planen. | | UPDATE- und DELETE-Operationen sind für Tabellen, die keinen Primärschlüssel haben, nicht zulässig. | Bevor Sie eine blue/green Bereitstellung erstellen, stellen Sie sicher, dass alle Tabellen über einen Primärschlüssel oder eine Verwendung `REPLICA IDENTITY FULL` verfügen. Verwenden Sie `REPLICA IDENTITY FULL` jedoch nur, wenn kein primärer oder eindeutiger Schlüssel vorhanden ist, da dies die Replikationsleistung beeinträchtigt. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). | ## Beschränkungen der Aurora Global Database für blue/green Bereitstellungen Zusätzlich zu den oben genannten allgemeinen und Engine-spezifischen Einschränkungen gelten die folgenden Einschränkungen für blue/green Bereitstellungen für Aurora Global Database: + Alle Operationen müssen von derselben Region aus initiiert werden wie der Writer-Cluster der Global Database. + Die Durchführung eines globalen Switchovers oder eines globalen Failovers führt dazu, dass die aktive blue/green Bereitstellung ungültig wird. Die blau-grüne Bereitstellung muss gelöscht und aus der neuen primären Region neu erstellt werden. + Wenn Sie für Aurora PostgreSQL die globale Schreibweiterleitung in Ihrer Produktionsumgebung aktiviert haben und eine blue/green Bereitstellung erstellen, ist die Schreibweiterleitung auf dem grünen Cluster deaktiviert. Sie wird in der grünen Umgebung erst nach dem blue/green Switchover aktiviert, wenn die grüne Umgebung zur neuen Produktionsumgebung wird. Nach dem Switchover ist die Schreibweiterleitung auf dem `-old1` Cluster deaktiviert. + Änderungen an der Topologie der globalen Datenbank nach der Erstellung der blue/green Bereitstellung führen dazu, dass die aktive blue/green Bereitstellung ungültig wird. Die blaugrüne Bereitstellung müsste gelöscht und aus der neuen primären Region neu erstellt werden. + Automatisierte Snapshots werden innerhalb der Backup-Aufbewahrungstage aufbewahrt, die ursprünglich in der alten blauen Umgebung konfiguriert waren. Automatisierte Snapshots aus dem alten blauen Cluster werden nicht in den grünen Cluster kopiert. + Globales Failover wird während eines blue/green Switchovers unterstützt, ein globales Switchover wird jedoch während eines Switchovers nicht unterstützt. blue/green + Stellen Sie sicher, dass DB-Cluster und DB-Parametergruppen für die grüne Umgebung in allen sekundären Regionen mit identischen Namen vorhanden sind. Wenn die Parametergruppe in einer Region nicht verfügbar ist, wird die Standardparametergruppe in den Regionen verwendet. + Vermeiden Sie die Verwendung von RDS Proxy für globale Datenbankmitglieder während des blue/green Bereitstellungs-Switchovers. ## Überlegungen zu Bereitstellungen blue/green Amazon RDS verfolgt Ressourcen in blue/green Bereitstellungen mit dem `DbClusterResourceId` Ende `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-*Cluster***-ID: Jede ist in der Datenbankkonfiguration in der RDS-Konsole aufgeführt. Der Name (Cluster-ID) einer Ressource ändert sich, wenn Sie eine blue/green Bereitstellung umstellen, 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 eine Umstellung der grünen Ressourcen auf die neuen Produktionsressourcen vornehmen, stimmen ihre Ressourcen-IDs nicht mit den blauen Ressourcen-IDs überein, die zuvor in der Produktion vorhanden waren. Nachdem Sie eine blue/green Bereitstellung umgestellt haben, sollten Sie erwägen, die Ressourcen-IDs auf die der neu umgestellten Produktionsressourcen für integrierte Funktionen und Dienste zu aktualisieren, die Sie zusammen 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 die Ressource CloudTrail für die Überwachung von Ressourcen verwenden, passen Sie die Anzahl der Benutzer so an, CloudTrail dass die neuen Ressourcen-IDs nach dem Switchover nachverfolgt werden. Weitere Informationen finden Sie unter [Überwachung von Amazon Aurora AWS CloudTrail](logging-using-cloudtrail.md). + 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äts-Streams](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md). + Wenn Sie die Performance-Insights-API verwenden, passen Sie die Ressourcen-IDs in API-Aufrufen nach der Umstellung an. Weitere Informationen finden Sie unter [Überwachen der DB-Auslastung mit Amazon CloudWatch Database Insights Amazon Aurora](USER_PerfInsights.md). 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 überführten Ressourcen hinzufügen. Weitere Informationen finden Sie unter [Identity and Access Management für Amazon Aurora](UsingWithRDS.IAM.md). + Wenn Sie Ihrem DB-Cluster IAM-Rollen zugeordnet haben, stellen Sie sicher, dass Sie diese nach der Umstellung erneut zuordnen. Angehängte Rollen werden nicht automatisch in die grüne Umgebung kopiert. + Wenn Sie sich mithilfe der [IAM-Datenbankauthentifizierung](UsingWithRDS.IAMDBAuth.md) 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](UsingWithRDS.IAMDBAuth.IAMPolicy.md). + 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](aurora-restore-snapshot.md). + Nach dem Umschalten können AWS Database Migration Service (AWS DMS) -Replikationsaufgaben nicht wieder aufgenommen 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](Aurora.Managing.Clone.md). + Wenn Sie dem DB-Cluster in der grünen Umgebung einer blue/green Bereitstellung eine DB-Instance hinzufügen, ersetzt die neue DB-Instance beim Umschalten 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 Bereitstellung löschen, können Sie keine neue DB-Instance erstellen, um sie in der blue/green Bereitstellung zu ersetzen. 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 `-old{{n}}` angefügt wird. + Jede Anwendung, die auf die DB-Instance in der blauen Umgebung verweist, verwendet nach der Umstellung weiterhin dieselbe DB-Instance. + Wenn Sie Ressourcen-Tags für die Zugriffskontrolle oder das Betriebsmanagement verwenden, müssen Sie sich darüber im Klaren sein, dass Tag-Änderungen zwischen blauen und grünen Umgebungen erst beim Switchover synchronisiert werden. Wenn Sie eine blue/green Bereitstellung erstellen, werden die Tags aus der blauen Umgebung in die grüne Umgebung kopiert. Nach der Erstellung werden alle Tag-Änderungen, die Sie an einer der beiden Umgebungen vornehmen, nicht automatisch synchronisiert. Beim Switchover ersetzen blaue Umgebungs-Tags alle Tags in der grünen Umgebung. Wenden Sie alle erforderlichen Tags auf die blaue Umgebung an, bevor Sie die blue/green Bereitstellung erstellen, oder wenden Sie die erforderlichen Tags nach der Umstellung erneut auf die neue Produktionsumgebung an. Weitere Informationen zu Tags erhalten Sie unter [Tagging Amazon Aurora undAmazon RDS-Ressourcen](USER_Tagging.md).