Umstellungs-Timeout Integrationsschutz der Umstellung Umstellungsaktionen Bewährte Methoden für die Umstellung CloudWatch Überprüfen der Metriken vor dem Switchover Überwachung der Replikatverzögerung vor der Umstellung Eine blue/green Bereitstellung umschalten Nach der Umstellung

Wechseln einer blue/green Bereitstellung in Amazon Aurora

Bei einer Umstellung wird der DB-Cluster einschließlich seiner DB-Instances in der grünen Umgebung zum Produktions-DB-Cluster gemacht. Vor der Umstellung wird der Produktionsdatenverkehr an den Cluster in der blauen Umgebung weitergeleitet. Nach der Umstellung wird der Produktionsdatenverkehr an den DB-Cluster in der grünen Umgebung weitergeleitet.

Das Umschalten einer blue/green Bereitstellung ist nicht dasselbe wie das Heraufstufen des grünen innerhalb der blue/green Bereitstellung. Wenn Sie den DB-Cluster der grünen manuell heraufstufen, indem Sie im Menü Aktionen die Option Heraufstufen wählen, wird die Replikation zwischen der blauen und der grünen Umgebung unterbrochen und die blue/green Bereitstellung wechselt in den Status Ungültige Konfiguration.

Themen

Umstellungs-Timeout
Integrationsschutz der Umstellung
Umstellungsaktionen
Bewährte Methoden für die Umstellung
CloudWatch Überprüfen der Metriken vor dem Switchover
Überwachung der Replikatverzögerung vor der Umstellung
Eine blue/green Bereitstellung umschalten
Nach der Umstellung

Umstellungs-Timeout

Sie können einen Umstellungs-Timeout zwischen 30 Sekunden und 3 600 Sekunden (eine Stunde) festlegen. Wenn die Umstellung länger als angegeben dauert, werden alle Änderungen rückgängig gemacht und es werden keine Änderungen an einer der Umgebungen vorgenommen. Der Standardwert für den Timeout beträgt 300 Sekunden (fünf Minuten).

Integrationsschutz der Umstellung

Wenn Sie eine Umstellung starten, führt Amazon RDS einige grundlegende Prüfungen durch, um zu testen, ob die blaue und die grüne Umgebung für die Umstellung bereit sind. Diese Prüfungen werden als Integrationsschutz der Umstellung. Dieser Integrationsschutz verhindert eine Umstellung, wenn die Umgebungen dafür nicht bereit sind. Mit diesem Schutz werden längere Ausfallzeiten als erwartet vermieden und Datenverluste zwischen der blauen und der grünen Umgebung verhindern, die sich ergeben könnten, wenn die Umstellung gestartet wird.

Amazon RDS führt die folgenden Integrationsschutzprüfungen in der grünen Umgebung durch:

Zustand der Replikation – Es wird geprüft, ob der Replikationsstatus des grünen DB-Clusters fehlerfrei ist. Der grüne DB-Cluster ist ein Replikat des blauen DB-Clusters.
Replikationsverzögerung – Es wird geprüft, ob die Replikatverzögerung des grünen DB-Clusters innerhalb der für die Umstellung zulässigen Grenzwerte liegt. Die zulässigen Grenzwerte basieren auf dem angegebenen Timeout-Zeitraum. Die Replikatverzögerung gibt an, wie weit der grüne DB-Cluster hinter seinem blauen DB-Cluster zurückbleibt. Weitere Informationen finden Sie unter Überwachung der Replikatverzögerung vor der Umstellung.
Aktive Schreibvorgänge – Es wird sichergestellt, dass es auf dem grünen DB-Cluster keine aktiven Schreibvorgänge gibt.

Amazon RDS führt die folgenden Integrationsschutzprüfungen in der blauen Umgebung durch:

Externe Replikation: stellt für Aurora PostgreSQL sicher, dass es sich bei der blauen Umgebung nicht um eine selbstverwaltete logische Quelle (Publisher) oder ein Replikat (Subscriber) handelt. Ist dies der Fall, empfehlen wir, die selbstverwalteten Replikations-Slots und Abonnements für alle Datenbanken in der blauen Umgebung zu löschen, mit der Umstellung fortzufahren und sie dann neu zu erstellen, um die Replikation fortzusetzen. Prüft für Aurora MySQL, ob die blaue Datenbank kein externes Binlog-Replikat ist. Ist dies der Fall, stellen Sie sicher, dass sie nicht aktiv repliziert wird.
Lang andauernde aktive Schreibvorgänge – Es wird sichergestellt, dass auf dem blauen DB-Cluster keine lang andauernden aktiven Schreibvorgänge vorhanden sind, da diese die Replikatverzögerung erhöhen können.
Lang andauernde DDL-Anweisungen – Es wird sichergestellt, dass auf dem blauen DB-Cluster keine lang andauernden DDL-Anweisungen vorhanden sind, da diese die Replikatverzögerung erhöhen können.
Nicht unterstützte PostgreSQL-Änderungen — Bei Aurora PostgreSQL RDS for blue/green PostgreSQL-Bereitstellungen in der blauen Umgebung keine DDL-Änderungen und keine Hinzufügungen oder Änderungen großer Objekte vorgenommen wurden. Weitere Informationen finden Sie unter Spezifische Einschränkungen für Bereitstellungen im Zusammenhang mit der logischen Replikation blue/green .

Wenn Amazon RDS nicht unterstützte PostgreSQL-Änderungen erkennt, ändert es den Replikationsstatus auf Replication degraded und benachrichtigt Sie, dass Switchover für die Bereitstellung nicht verfügbar ist. blue/green Um mit dem Switchover fortzufahren, empfehlen wir, die Bereitstellung und alle grünen Datenbanken zu löschen und neu zu erstellen. blue/green Wählen Sie dazu Aktionen, Mit grünen Datenbanken löschen aus.

Umstellungsaktionen

Wenn Sie zu einer blue/green Bereitstellung wechseln, führt RDS die folgenden Aktionen aus:

Es führt Integritätsschutzprüfungen durch, um zu überprüfen, ob die blaue und die grüne Umgebung bereit für die Umstellung sind.
Es stoppt neue Schreibvorgänge auf dem DB-Cluster in beiden Umgebungen.
Es trennt Verbindungen mit den DB-Instances in beiden Umgebungen und erlaubt keine neuen Verbindungen.
Es wartet, bis die Replikation in der grünen Umgebung aufgeholt hat, sodass die grüne Umgebung mit der blauen Umgebung synchron ist.
Es benennt den DB-Cluster und die DB-Instances in beiden Umgebungen um.

RDS benennt den DB-Cluster und die DB-Instances in der grünen Umgebung um, sodass sie dem jeweiligen DB-Cluster und den DB-Instances in der blauen Umgebung entsprechen. Angenommen, der Name einer DB-Instance in der blauen Umgebung lautet mydb. Nehmen wir außerdem an, dass der Name der entsprechenden DB-Instance in der grünen Umgebung mydb-green-abc123 lautet. Während der Umstellung wird der Name der DB-Instance in der grünen Umgebung in mydb geändert.

RDS benennt den DB-Cluster und die DB-Instances in der blauen Umgebung um, indem -oldn an den aktuellen Namen angehängt wird, wobei n eine Zahl ist. Angenommen, der Name einer DB-Instance in der blauen Umgebung lautet mydb. Nach der Umstellung könnte der Name der DB-Instance mydb-old1 lauten.

RDS benennt auch die Endpunkte in der grünen Umgebung um, sodass sie mit den entsprechenden Endpunkten in der blauen Umgebung übereinstimmen und keine Anwendungsänderungen erforderlich sind.
Erlaubt Verbindungen mit Datenbanken in beiden Umgebungen.
Erlaubt neue Schreibvorgänge auf dem DB-Cluster in der neuen Produktionsumgebung.

Nach der Umstellung erlaubt der DB-Cluster der vorherigen Produktion nur Lesevorgänge. Selbst wenn Sie Schreibvorgänge auf dem DB-Cluster aktivieren, bleibt dieser schreibgeschützt, bis Sie die blue/green Bereitstellung löschen.

Sie können den Status einer Umstellung mit Amazon EventBridge überwachen. Weitere Informationen finden Sie unter Blau/Grün-Bereitstellungsereignisse.

Beim Switchover ersetzen Tags aus der blauen Umgebung alle Tags auf Ressourcen in der grünen Umgebung. Alle Tags, die Sie direkt zu Ressourcen der grünen Umgebung hinzugefügt haben, werden während dieses Vorgangs überschrieben. Weitere Informationen zu Tags erhalten Sie unter Taggen von Amazon-Aurora- und Amazon-RDS-Ressourcen.

Wenn die Umstellung startet und aus irgendeinem Grund vorzeitig beendet wird, werden alle Änderungen rückgängig gemacht und es werden keine Änderungen an einer der Umgebungen vorgenommen.

Bewährte Methoden für die Umstellung

Wir empfehlen Ihnen dringend, sich an bewährte Methoden zu halten und vor der Umstellung die folgenden Aufgaben auszuführen:

Testen Sie die Ressourcen in der grünen Umgebung gründlich. Stellen Sie sicher, dass sie ordnungsgemäß und effizient funktionieren.
Überwachen Sie relevante CloudWatch Amazon-Metriken. Weitere Informationen finden Sie unter CloudWatch Überprüfen der Metriken vor dem Switchover.
Ermitteln Sie den besten Zeitpunkt für die Umstellung.

Während der Umstellung werden Schreibvorgänge in beiden Umgebungen von den Datenbanken abgeschnitten. Ermitteln Sie einen Zeitpunkt, an dem der Datenverkehr in Ihrer Produktionsumgebung am niedrigsten ist. Transaktionen mit langer Laufzeit, z. B. aktive DDLs, können Ihre Umstellungszeit verlängern, was zu längeren Ausfallzeiten Ihrer Produktionsworkloads führt.

Wenn es eine große Anzahl von Verbindungen auf Ihren und Ihren DB-Instances gibt, sollten Sie erwägen, diese manuell auf das für Ihre Anwendung erforderliche Minimum zu reduzieren, bevor Sie die Bereitstellung umstellen. blue/green Eine Möglichkeit, dies zu erreichen, besteht darin, ein Skript zu erstellen, das den Status der blue/green Bereitstellung überwacht und mit der Bereinigung der Verbindungen beginnt, wenn es feststellt, dass sich der Status zu geändert hatSWITCHOVER_IN_PROGRESS.
Stellen Sie sicher, dass der DB-Cluster und die DB-Instances in beiden Umgebungen den Status Available aufweisen.
Stellen Sie sicher, dass der DB-Cluster in der grünen Umgebung fehlerfrei ist und repliziert wird.
Stellen Sie sicher, dass Ihre Netzwerk- und Client-Konfigurationen den DNS-Cache Time-To-Live (TTL) nicht über fünf Sekunden hinaus erhöhen. Dies ist die Standardeinstellung für Aurora .  Andernfalls senden Anwendungen nach der Umstellung weiterhin Schreibdatenverkehr an die blaue Umgebung.
Gehen Sie für Aurora blue/green PostgreSQL-Bereitstellungen, wie folgt vor:
- Überprüfen Sie vor der Umstellung die Einschränkungen der logischen Replikation und ergreifen Sie alle erforderlichen Maßnahmen. Weitere Informationen finden Sie unter Spezifische Einschränkungen für Bereitstellungen im Zusammenhang mit der logischen Replikation blue/green .
- Führen Sie die ANALYZE-Operation aus, um die Tabelle pg_statistics zu aktualisieren. Dadurch verringert sich das Risiko, dass nach der Umstellung Leistungsprobleme auftreten.

Anmerkung

Während einer Umstellung können Sie keinen der DB-Cluster in der Umstellung ändern.

CloudWatch Überprüfen der Metriken vor dem Switchover

Bevor Sie zu einer blue/green Bereitstellung wechseln, empfehlen wir Ihnen, die Werte der folgenden Kennzahlen bei Amazon zu überprüfen CloudWatch.

DatabaseConnections— Verwenden Sie diese Kennzahl, um den Grad der Aktivität bei der blue/green Bereitstellung abzuschätzen und sicherzustellen, dass der Wert für Ihre Bereitstellung akzeptabel ist, bevor Sie umsteigen. Wenn Performance Insights aktiviert ist, ist DBLoad eine genauere Metrik.
ActiveTransactions – Wenn innodb_monitor_enable in der DB-Parametergruppe für eine Ihrer DB-Instances auf all gesetzt ist, verwenden Sie diese Metrik, um festzustellen, ob es eine hohe Anzahl aktiver Transaktionen gibt, die die Umstellung blockieren könnten.

Weitere Informationen finden Sie unter CloudWatch Amazon-Metriken für Amazon Aurora.

Überwachung der Replikatverzögerung vor der Umstellung

Stellen Sie vor dem Umstieg auf eine blue/green Bereitstellung sicher, dass die Replikatverzögerung nahezu Null ist, um Ausfallzeiten zu reduzieren.

Aurora MySQL

Überprüfen Sie bei MySQL die AuroraBinlogReplicaLag CloudWatch Metrik in der grünen Umgebung, um die aktuelle Replikatverzögerung zu ermitteln. Weitere Informationen finden Sie unter Diagnose und Lösung bei Verzögerungen zwischen Read Replicas (Lesereplikaten).

Aurora PostgreSQL

Überprüfen Sie bei blue/green PostgreSQL-Bereitstellungen, die OldestReplicationSlotLag CloudWatch Metrik in der blauen Umgebung, um die aktuelle Replikatverzögerung zu ermitteln. Weitere Informationen finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

Darüber hinaus können Sie die folgende SQL-Abfrage in der blauen Umgebung ausführen:


SELECT slot_name,
       confirmed_flush_lsn as flushed,
       pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192

confirmed_flush_lsn stellt die letzte Log-Sequenznummer (LSN) dar, die an das Replikat gesendet wurde. pg_current_wal_lsn stellt dar, wo sich die Datenbank jetzt befindet. Ist lsn_distance 0, bedeutet das, dass das Replikat keine Verzögerung aufweist.

Eine blue/green Bereitstellung umschalten

Sie können eine blue/green Bereitstellung mithilfe der AWS-Managementkonsole, der oder der AWS CLI RDS-API umschalten.

Um eine blue/green Bereitstellung umzuschalten

Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
Wählen Sie im Navigationsbereich Datenbanken und dann die blue/green Bereitstellung aus, zu der Sie wechseln möchten.
Wählen Sie unter Actions (Aktionen) die Option Switch over (Umstellen) aus.

Die Seite Switch Over (Umstellen) wird angezeigt.
Sehen Sie sich auf der Seite Switchover (Umstellen) die Umstellungszusammenfassung an. Stellen Sie sicher, dass die Ressourcen in beiden Umgebungen Ihren Erwartungen entsprechen. Wenn dies nicht der Fall ist, wählen Sie Cancel (Abbrechen) aus.
Geben Sie unter Timeout-Einstellungen das Zeitlimit für die Umstellung ein.
Wenn in Ihrem Cluster Aurora PostgreSQL ausgeführt wird, überprüfen und bestätigen Sie die vor der Umstellung zu berücksichtigenden Empfehlungen. Weitere Informationen finden Sie unter Spezifische Einschränkungen für Bereitstellungen im Zusammenhang mit der logischen Replikation blue/green .
Wählen Sie Switch over (Umstellen) aus.

Um eine blue/green Bereitstellung mithilfe von umzuschalten AWS CLI, verwenden Sie den switchover-blue-green-deploymentBefehl mit den folgenden Optionen:

--blue-green-deployment-identifier— Geben Sie die Ressourcen-ID der blue/green Bereitstellung an.
--switchover-timeout – Geben Sie das Zeitlimit für die Umstellung in Sekunden an. Der Standardwert ist 300.

Beispiel Wechseln Sie zu einer blue/green Bereitstellung

Für Linux, macOS oder Unix:


aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

Für Windows:


aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

Um eine blue/green Bereitstellung mithilfe der Amazon RDS-API umzuschalten, verwenden Sie den SwitchoverBlueGreenDeploymentVorgang mit den folgenden Parametern:

BlueGreenDeploymentIdentifier— Geben Sie die Ressourcen-ID der blue/green Bereitstellung an.
SwitchoverTimeout – Geben Sie das Zeitlimit für die Umstellung in Sekunden an. Der Standardwert ist 300.

Nach der Umstellung

Nach einer Umstellung werden der DB-Cluster und die DB-Instances in der vorherigen blauen Umgebung beibehalten. Für diese Ressourcen fallen die Standardkosten an. Die Replikation und die binäre Protokollierung zwischen der blauen und der grünen Umgebung werden gestoppt.

RDS benennt den DB-Cluster und die DB-Instances in der blauen Umgebung um, indem -oldn an den aktuellen Namen angehängt wird, wobei n eine Zahl ist. Der blaue DB-Cluster wird in einen schreibgeschützten Zustand versetzt. Selbst wenn Sie Schreibvorgänge aktivieren, bleibt sie schreibgeschützt, bis Sie die blue/green Bereitstellung löschen. RDS nennt den DB-Cluster und die DB-Instances in der grünen Umgebung -newn.

Wenn Sie die blue/green Bereitstellungsressource löschen, behält RDS die Ressourcen -oldn und -newn bei.

Nach dem Umschalten einer blue/green Bereitstellung

Aktualisieren des übergeordneten Knotens für Verbraucher

RDS bietet vollständig verwaltete Lesereplikate. Es bietet jedoch auch die Möglichkeit, selbstverwaltete Replikate einzurichten, die auch als externe Replikate bezeichnet werden. Mit externen Replikaten können Sie Ressourcen von Drittanbietern als Replikationsziele verwenden.

Wenn Sie eine umgestellt haben und der DB-Cluster der blauen vor dem Switchover externe Replikate oder Binärprotokollverbraucher hatte, müssen Sie deren übergeordneten Knoten nach dem Switchover aktualisieren, um die Kontinuität der Replikation aufrechtzuerhalten.

So ändern Sie den übergeordneten Knoten

Nach der Umstellung gibt die Writer-DB-Instance, die sich zuvor in der grünen Umgebung befand, ein Ereignis aus, das den Namen der Master-Protokolldatei und die Position des Master-Protokolls enthält. Navigieren Sie zur RDS-Konsole und wählen Sie im linken Navigationsbereich die Option Ereignisse aus, um das Ereignis ausfindig zu machen.
Filtern Sie vor der Umstellung nach Ereignissen, bei denen die Quelle der Name der alten grünen Writer-DB-Instance ist.
Suchen Sie das Ereignis, das die Koordinaten des Binärprotokolls enthält. Die Ereignismeldung sieht ungefähr so aus: Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574.
Stellen Sie sicher, dass der Consumer oder das Replikat alle Binärprotokolle aus der alten blauen Umgebung übernommen hat. Verwenden Sie dann die bereitgestellten Koordinaten des Binärprotokolls, um die Replikation auf den Consumern fortzusetzen. Wenn Sie beispielsweise ein MySQL-Replikat auf ausführen EC2, können Sie die folgenden Befehle verwenden:

MySQL 8.0.22 und niedrigere Haupt- und Nebenversionen
```
CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
```
MySQL 8.0.23 und höhere Haupt- und Nebenversionen
```
CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
```

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Anzeigen einer Blau/Grün-Bereitstellung

Löschen einer Blau/Grün-Bereitstellung