Wechseln einer blue/green Bereitstellung in Amazon RDS - Amazon Relational Database Service

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.

Wechseln einer blue/green Bereitstellung in Amazon RDS

Bei einer Umstellung wird die Staging-Umgebung zur neuen Produktionsumgebung gemacht. Wenn die grüne DB-Instance über Lesereplikate verfügt, werden diese ebenfalls umgestellt. Vor der Umstellung wird der Produktionsdatenverkehr an die DB-Instance und die Lesereplikate in der blauen Umgebung weitergeleitet. Nach der Umstellung wird der Produktionsdatenverkehr an die DB-Instance und die Lesereplikate 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 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.

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 der grünen primären DB-Instance fehlerfrei ist. Die grüne primäre DB-Instance ist ein Replikat der blauen primären DB-Instance.

  • Replikationsverzögerung – Es wird geprüft, ob die Replikatverzögerung der grünen primären DB-Instance 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 die grüne primäre DB-Instance hinter ihrer blauen primären DB-Instance zurückbleibt. Weitere Informationen finden Sie unter Überwachung der Replikatverzögerung vor der Umstellung.

  • Aktive Schreibvorgänge – Es wird sichergestellt, dass es auf der grünen primären DB-Instance keine aktiven Schreibvorgänge gibt.

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

  • Externe Replikation: stellt für RDS für 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 RDS für MySQL und RDS für MariaDB, 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 der blauen primären DB-Instance 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 der blauen primären DB-Instance keine lang andauernden DDL-Anweisungen vorhanden sind, da diese die Replikatverzögerung erhöhen können.

  • Nicht unterstützte PostgreSQL-Änderungen — Bei , die logische Replikation verwenden, wird sichergestellt, dass 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:

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

  2. Es stoppt neue Schreibvorgänge auf der primären DB-Instance in beiden Umgebungen.

  3. Es trennt Verbindungen mit den DB-Instances in beiden Umgebungen und erlaubt keine neuen Verbindungen.

  4. Es wartet, bis die Replikation in der grünen Umgebung aufgeholt hat, sodass die grüne Umgebung mit der blauen Umgebung synchron ist.

  5. Es benennt die DB-Instances in beiden Umgebungen um.

    RDS benennt die DB-Instances in der grünen Umgebung um, sodass sie den jeweiligen 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 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.

  6. Erlaubt Verbindungen mit Datenbanken in beiden Umgebungen.

  7. Erlaubt neue Schreibvorgänge auf der primären DB-Instance in der neuen Produktionsumgebung.

    Nach der Umstellung erlaubt die primäre DB-Instance der vorherigen Produktion nur Lesevorgänge, bis Sie den Parameter read_only (für RDS für MySQL) oder den Parameter default_transaction_read_only (für RDS für PostgreSQL) auf 0 festlegen und die DB-Instance neu starten.

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-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 DB-Instances, Ihrem DB-Cluster 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 die DB-Instances in beiden Umgebungen den Status Available aufweisen.

  • Stellen Sie sicher, dass die primäre DB-Instance 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 RDS-DNS-Zonen.
 Andernfalls senden Anwendungen nach der Umstellung weiterhin Schreibdatenverkehr an die blaue Umgebung.

  • Stellen Sie sicher, dass das Laden der Daten abgeschlossen ist, bevor Sie umstellen. Weitere Informationen finden Sie unter Lazy Loading und Speicherinitialisierung für Blau/Grün-Bereitstellungen.

  • Gehen Sie für , RDS für blue/green PostgreSQL-Bereitstellungen, die logische Replikation verwenden, wie folgt vor:

Anmerkung

Während einer Umstellung können Sie keine der DB-Instances in der Umstellung ändern.

CloudWatch Überprüfen der Metriken vor dem Switchover

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

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

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

RDS für MySQL und RDS für MariaDB

Überprüfen Sie bei MySQL - und blue/green MariaDB-Bereitstellungen die 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).

RDS für PostgreSQL

Für blue/green PostgreSQL-Bereitstellungen, die physische Replikation verwenden, finden Sie Anweisungen Überwachen und Optimieren des Replikationsprozesses zur Identifizierung der aktuellen Replikatverzögerung unter.

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

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 Erläuterung, wann bei blue/green Bereitstellungen physische Replikation und wann logische Replikation verwendet wird, finden Sie unter. Replikationsmethoden in PostgreSQL für Blau/Grün-Bereitstellungen

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
  1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Datenbanken und dann die blue/green Bereitstellung aus, zu der Sie wechseln möchten.

  3. Wählen Sie unter Actions (Aktionen) die Option Switch over (Umstellen) aus.

    Die Seite Switch Over (Umstellen) wird angezeigt.

    Wechseln Sie zur blue/green Bereitstellung
  4. 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.

  5. Geben Sie unter Timeout-Einstellungen das Zeitlimit für die Umstellung ein.

  6. Wenn in Ihrem ClusterIhrer Instance RDS für 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 .

  7. 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 die DB-Instances in der vorherigen blauen Umgebung beibehalten. Für diese Ressourcen fallen die Standardkosten an. Die Replikation zwischen der blauen und der grünen Umgebung werden gestoppt.

RDS benennt die DB-Instances in der blauen Umgebung um, indem -oldn an den aktuellen Namen angehängt wird, wobei n eine Zahl ist. Die DB-Instances in der alten blauen Umgebung sind schreibgeschützt, bis Sie den Parameter read_only (für RDS für MySQL) oder den Parameter default_transaction_read_only (für RDS für PostgreSQL) auf 0 festlegen. RDS nennt 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 RDS for MariaDB- oder RDS for MySQL umgestellt haben und der 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
  1. Nach der Umstellung gibt die -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.

  2. Filtern Sie vor der Umstellung nach Ereignissen, bei denen die Quelle der Name der alten grünen -DB-Instance ist.

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

  4. 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;

Wenn der Consumer eine andere DB-Instance von RDS für MySQL oder RDS für MariaDB ist, führen Sie die folgenden gespeicherten Vorgänge der Reihe nach aus:

  1. mysql.rds_stop_replication

  2. mysql.rds_reset_external_master (für Version 8.0 und niedriger) oder mysql_rds_reset_external_source (für Version 8.4 und höher)

  3. mysql.rds_set_external_master (für Version 8.0 und niedriger) oder mysql_rds_set_external_source (für Version 8.4 und höher)

  4. mysql.rds_start_replication