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 Amazon RDS Amazon
Im Folgenden finden Sie bewährte Methoden für blue/green Bereitstellungen.
**Topics**
+ [Allgemeine bewährte Methoden für Bereitstellungen blue/green](#blue-green-deployments-best-practices-general)
+ [RDS für MySQL — Bewährte Methoden für blue/green Bereitstellungen](#blue-green-deployments-best-practices-mysql)
+ [Bewährte Methoden für blue/green Bereitstellungen von RDS für MySQL](#blue-green-deployments-best-practices-agd)
+ [PostgreSQL-Replikationsmethoden für Bereitstellungen blue/green](blue-green-deployments-replication-type.md)
## 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 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 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](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) sowie unter [Einschränkungen](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) in der Dokumentation zur logischen Replikation in PostgreSQL.
**Anmerkung**
Diese Einschränkung gilt nicht für RDS for blue/green PostgreSQL-Bereitstellungen, die physische Replikation verwenden. Weitere Informationen finden Sie unter [Einschränkungen von RDS für PostgreSQL für blue/green Bereitstellungen mit physischer Replikation](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical).
+ Nachdem Sie die blue/green Bereitstellung erstellt haben, kümmern Sie sich bei Bedarf um verzögertes Laden. Stellen Sie sicher, dass das Laden der Daten abgeschlossen ist, bevor Sie umstellen. Weitere Informationen finden Sie unter [Verzögertes Laden und Speicherinitialisierung für Bereitstellungen blue/green](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading).
+ 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](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices).
## RDS für MySQL — Bewährte Methoden für blue/green Bereitstellungen
Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blue/green Bereitstellung aus einem erstellen.
+ Vermeiden Sie die Verwendung von nicht-transaktionalen Speicher-Engines wie MyISAM, die nicht für die Replikation optimiert sind.
+ Optimieren Sie die Lesereplikate und die grüne Umgebung für die binäre Protokollreplikation. Falls von Ihrer DB-Engine unterstützt, aktivieren Sie GTID-, parallel und absturzsichere Replikation, um Datenkonsistenz und Beständigkeit zu gewährleisten, bevor Sie Ihre Bereitstellung erstellen. blue/green Weitere Informationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md).
+ Wenn es in der grünen Umgebung zu Replikatverzögerungen kommt, sollten Sie die folgenden Schritte ausführen:
+ Setzen Sie den Parameter `innodb_flush_log_at_trx_commit` in der grünen DB-Parametergruppe vorübergehend auf `2`. 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.
+ Um die Schreiblatenz zu reduzieren und den Replikationsdurchsatz zu erhöhen, ändern Sie vorübergehend grüne Multi-AZ-DB-Instances zu Single-AZ-DB-Instances. Aktivieren Sie Multi-AZ unmittelbar vor der Umstellung erneut.
## Bewährte Methoden für blue/green Bereitstellungen von RDS für MySQL
Zusätzlich zu den oben aufgeführten allgemeinen und Engine-spezifischen Best Practices sollten Sie die folgenden Best Practices für die RDS for MySQL-DB-Instance
+ Ü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
### Bewährte Methoden für Bereitstellungen in RDS für PostgreSQL blue/green
Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blue/green Bereitstellung aus einer RDS for PostgreSQL-DB-Instance erstellen.
**Topics**
+ [Allgemeine bewährte Methoden für Bereitstellungen von RDS für PostgreSQL blue/green](#blue-green-deployments-best-practices-postgres-general)
+ [Bewährte Methoden für RDS für PostgreSQL für blue/green Bereitstellungen mit physischer Replikation](#blue-green-deployments-best-practices-postgres-physical)
+ [Bewährte Methoden für RDS für PostgreSQL für blue/green Bereitstellungen mit logischer Replikation](#blue-green-deployments-best-practices-postgres-logical)
#### Allgemeine bewährte Methoden für Bereitstellungen von RDS für PostgreSQL blue/green
Beachten Sie die folgenden allgemeinen bewährten Methoden, wenn Sie eine blue/green Bereitstellung aus einer RDS for PostgreSQL-DB-Instance erstellen.
+ 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 in Datenbank von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ 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, 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
+ Deaktivieren Sie für PostgreSQL Version 12 und höher den Parameter `index_cleanup` 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](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
**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.
+ 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.
+ Um zu verhindern, dass Write-Ahead-Log-(WAL)-Segmente aus der blauen Umgebung entfernt werden, setzen Sie den Parameter `wal_keep_segments` für PostgreSQL Version 13 und niedriger auf 15625. Für Version 14 und höher setzen Sie den Parameter `wal_keep_size` auf 1 TiB, wenn genügend freier Speicherplatz vorhanden ist.
#### Bewährte Methoden für RDS für PostgreSQL für blue/green Bereitstellungen mit physischer Replikation
Bei physischer Replikation erstellt Amazon RDS ein Lesereplikat der Quell-DB-Instance. Informationen zu verwandten Parametern, Überwachung, Optimierung und Fehlerbehebung finden Sie unter [Arbeiten mit Read Replicas in Amazon RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
Eine Erläuterung, wann blue/green Bereitstellungen physische Replikation statt logischer Replikation verwenden, finden Sie unter. [PostgreSQL-Replikationsmethoden für Bereitstellungen blue/green](blue-green-deployments-replication-type.md)
#### Bewährte Methoden für RDS für PostgreSQL für blue/green Bereitstellungen mit logischer Replikation
Beachten Sie die folgenden bewährten Methoden, wenn Sie eine blue/green Bereitstellung erstellen, die logische Replikation verwendet. Eine Erläuterung, wann blue/green Bereitstellungen logische Replikation statt physischer Replikation verwenden, finden Sie unter[PostgreSQL-Replikationsmethoden für Bereitstellungen blue/green](blue-green-deployments-replication-type.md).
+ Wenn in Ihrer 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. Weitere Informationen finden Sie in der [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM).
+ Mithilfe der Metrik können Sie den Transaktionsüberlauf überwachen, der auf die `ReplicationSlotDiskUsage` CloudWatch Festplatte geschrieben wird. 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 CloudWatch auf Amazon-Instanzebene für Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
+ In RDS für PostgreSQL Version 14 und höher können Sie die Größe logischer Überlaufdateien mithilfe der Systemansicht `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` überwachen.
+ Wenn Sie die `aws_s3`-Erweiterung verwenden, stellen Sie sicher, dass Sie dem DB-Cluster 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. Detaillierte Anweisungen finden Sie unter [Einrichten des Zugriffs auf einen Amazon-S3-Bucket](postgresql-s3-export-access-bucket.md).
+ Ü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.
+ 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 Sie eine höhere Engine-Version für die grüne Umgebung angeben, führen Sie die `ANALYZE`-Vorgang für alle Datenbanken aus, um die Tabelle `pg_statistic` 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 Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
+ 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.
# PostgreSQL-Replikationsmethoden für Bereitstellungen blue/green
Amazon RDS for PostgreSQL verwendet hauptsächlich physische Replikation für blue/green Bereitstellungen. Wenn Sie jedoch bei der Erstellung der blue/green Bereitstellung ein Upgrade der Hauptversion anfordern und Ihre Quell-DB-Instance eine der in der Tabelle unten aufgeführten PostgreSQL-Versionen ausführt, verwendet Amazon RDS stattdessen logische Replikation.
In der folgenden Tabelle wird beschrieben, wann Amazon RDS physische und wann logische Replikation für blue/green PostgreSQL-Bereitstellungen verwendet.
| Version der Quell-Instance der PostgreSQL-DB | Upgrade-Aktion bei der Bereitstellung blue/green | Replikationsmethode |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/blue-green-deployments-replication-type.html) | Hauptversions-Upgrade(die grüne Instance auf einer höheren Engine-Hauptversion als die blaue) | Logische Replikation |
| Alle unterstützten Versionen | Nebenversion-Upgrade oder kein Upgrade(die grüne Instance auf der gleichen Engine-Hauptversion wie die blaue) | Physikalische Replikation |
**Anmerkung**
Hauptversions-Upgrades werden für blue/green Bereitstellungen mit Quell-RDS für PostgreSQL, Versionen 15.3 und niedriger, 14.8 und niedriger, 13.11 und niedriger, 12.15 und niedriger oder 11.20 und niedriger, nicht unterstützt.
Informationen zu den Einschränkungen von blue/green Bereitstellungen, die physische und logische Replikation verwenden, finden Sie in den folgenden Abschnitten:
+ [Einschränkungen von RDS für PostgreSQL für blue/green Bereitstellungen mit physischer Replikation](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical)
+ [Einschränkungen von RDS for PostgreSQL für Bereitstellungen mit logischer Replikation blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-logical)