Einschränkungen und Überlegungen für Amazon RDS Amazon - Amazon Relational Database Service
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 Amazon RDS Amazon

Blau/Grün-Bereitstellungen in Amazon RDS erfordern eine sorgfältige Abwägung von Faktoren wie Replikations-Slots, Ressourcenmanagement, Instance-Größe und potenziellen 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.

Einschränkungen für Bereitstellungen blue/green

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:

  • Blau/Grün-Bereitstellungen unterstützen nicht die Verwaltung von Master-Benutzerpasswörtern mit AWS Secrets Manager.

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

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

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

  • Sie können eine blaue DB-Instance nicht auf eine höhere Engine-Version als die der entsprechenden grünen DB-Instance ä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

    • Kaskadierende Lesereplikate

    • Regionsübergreifende Lesereplikate

    • 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 Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS.

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

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

  • Die blaue DB-Instance kann kein externes Binlog-Replikat sein.

  • Wenn die Quelldatenbank einer benutzerdefinierten Optionsgruppe zugeordnet ist, können Sie bei der Erstellung der blue/green Bereitstellung kein Hauptversions-Upgrade angeben.

    In diesem Fall können Sie eine blue/green 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.

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

Einschränkungen von RDS für PostgreSQL für blue/green Bereitstellungen mit physischer Replikation

Die folgenden Einschränkungen gelten für RDS for blue/green PostgreSQL-Bereitstellungen, die physische Replikation verwenden. Eine Erläuterung, wann blue/green Bereitstellungen physische Replikation statt logischer Replikation verwenden, finden Sie unter. Replikationsmethoden in PostgreSQL für Blau/Grün-Bereitstellungen

  • Nachdem die grüne Umgebung erstellt wurde, können Sie kein manuelles Upgrade der Hauptversion durchführen.

  • Blaue/grüne Bereitstellungen, die physische Replikation verwenden, unterstützen keine Schemaänderungen in der grünen Umgebung, da diese strikt schreibgeschützt ist.

  • Bei der blauen DB-Instance kann es sich nicht um eine logische Quelle (Publisher) oder ein Replikat (Subscriber) handeln.

  • Blau/Grün-Bereitstellungen haben die folgenden Einschränkungen bei der Konfiguration der verzögerten Replikation in RDS für PostgreSQL:

    • Grüne Quell-Instance – Der Parameter recovery_min_apply_delay parameter wird ignoriert, auch wenn er in der Parametergruppe konfiguriert ist. Alle Verzögerungseinstellungen auf der grünen Quell-Instance werden nicht wirksam.

    • Grüne Replikat-Instance – Der Parameter recovery_min_apply_delay parameter wird vollständig unterstützt und auf die PostgreSQL-Konfigurationsdatei angewendet. Die Verzögerungseinstellungen funktionieren während des Umstellungs-Workflows erwartungsgemäß.

    • Eine verzögerte Replikation ist nicht mit Blue/Green RDS-Bereitstellungen für Hauptversions-Upgrades kompatibel.

Einschränkungen von RDS for PostgreSQL für Bereitstellungen mit logischer Replikation blue/green

Die folgenden Einschränkungen gelten für Blau/Grün-Bereitstellungen für RDS für PostgreSQL, die logische Replikation verwenden. Eine Erläuterung, wann blue/green Bereitstellungen logische Replikation statt physischer Replikation verwenden, finden Sie unter. Replikationsmethoden in PostgreSQL für Blau/Grün-Bereitstellungen

  • Nicht protokollierte Tabellen werden nicht in die grüne Umgebung repliziert,.

  • Bei der blauen DB-Instance kann es sich nicht um eine logische Quelle (Publisher) oder ein Replikat (Subscriber) handeln.

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

  • 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 die DB-Instance 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 in der Quell-Instance zu verringern.

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

  • Blau/Grün-Bereitstellungen haben die folgenden Einschränkungen bei der Konfiguration der verzögerten Replikation in RDS für PostgreSQL:

    • Grüne Quell-Instance – Der Parameter recovery_min_apply_delay parameter wird ignoriert, auch wenn er in der Parametergruppe konfiguriert ist. Alle Verzögerungseinstellungen auf der grünen Quell-Instance werden nicht wirksam.

    • Grüne Replikat-Instance – Der Parameter recovery_min_apply_delay parameter wird vollständig unterstützt und auf die PostgreSQL-Konfigurationsdatei angewendet. Die Verzögerungseinstellungen funktionieren während des Umstellungs-Workflows erwartungsgemäß.

    • Eine verzögerte Replikation ist nicht mit Blue/Green RDS-Bereitstellungen für Hauptversions-Upgrades kompatibel.

  • Das Erstellen neuer Partitionen in partitionierten Tabellen wird bei Blau/Grün-Bereitstellungen für RDS für PostgreSQL nicht unterstützt. 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 sein, 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.

    • 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 Einrichten der pgAudit-Erweiterung.

Spezifische Einschränkungen für Bereitstellungen im Zusammenhang mit der logischen Replikation 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 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. 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 Amazon RDS 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.
Data Control Language (DCL)-Anweisungen wie GRANT und REVOKE werden nicht von der blauen in die grüne Umgebung repliziert.

Wenn Amazon RDS PostgreSQL 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 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.
Große Objekte in der blauen Umgebung werden nicht in die grüne Umgebung repliziert. Dies gilt sowohl für bestehende große Objekte als auch für alle während des blue/green Bereitstellungsprozesses neu erstellten oder geänderten großen Objekte.

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. Sie müssen die blue/green Bereitstellung und alle grünen Datenbanken löschen und sie dann neu erstellen.

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 einer Umstellung 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 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.

Überlegungen zu blue/green Bereitstellungen

Amazon RDS verfolgt Ressourcen in blue/green Bereitstellungen mit dem 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: Jede ist in der Datenbankkonfiguration in der RDS-Konsole aufgeführt.

Der Name (Instanz-ID) einer Ressource ändert sich, wenn Sie zu einer blue/green Bereitstellung wechseln, aber jede Ressource behält 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 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 Überwachung von Amazon RDS-API-Aufrufen in AWS CloudTrail.

  • 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 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 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 Identity and Access Management für Amazon RDS.

  • Wenn Sie Ihrer DB-Instance 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 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 den IDs Ressourcenverbrauch nach AWS Backup dem Switchover an. Weitere Informationen finden Sie unter Verwenden von AWS Backup zum automatisierten Verwalten von Backups für Amazon RDS.

  • Wenn Sie einen manuellen oder automatisierten DB-Snapshot für eine DB-Instance wiederherstellen möchten, die Teil einer blue/green 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 auf eine DB-Instance.

  • 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 auf einen bestimmten Zeitpunkt für Amazon RDS.

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

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

  • Wenn Sie eine DB-Instance 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 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.

  • Wenn Sie Ressourcen-Tags für die Zugriffskontrolle oder das Betriebsmanagement verwenden, müssen Sie sich darüber im Klaren sein, dass Tag-Änderungen erst beim Switchover zwischen blauen und grünen Umgebungen synchronisiert werden. Wenn Sie eine blue/green Bereitstellung erstellen, werden Tags aus der blauen Umgebung in die grüne Umgebung kopiert. Nach der Erstellung werden alle Tag-Änderungen, die Sie an einer der 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 dem Switchover erneut auf die neue Produktionsumgebung an. Weitere Informationen zu Tags erhalten Sie unter Taggen von Amazon-RDS-Ressourcen.