Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Blau/Grün-Bereitstellungen in Cloud SQL

MySQL | PostgreSQL | SQL Server

Dieses Dokument bietet einen Überblick über Blau/Grün-Bereitstellungen von Cloud SQL, mit denen Sie Datenbankupdates wie Upgrades der Hauptversion und Hardwareänderungen durchführen und gleichzeitig Ausfallzeiten minimieren können.

Bereitstellungsabsichten und Anwendungsfälle

Sie können eine Blau/Grün-Bereitstellung mit oder ohne Absicht erstellen, ein Upgrade der Hauptversion durchzuführen:

Mit Absicht erstellen (Upgrade der Hauptversion): Aktualisiert Ihre Datenbank-Engine auf eine neuere Hauptversion. Während der Bereitstellungserstellung führt Cloud SQL die API für die Vorabprüfung des Upgrades der Hauptversion aus, um die Kompatibilität zu prüfen, bevor mit dem Upgrade-Workflow fortgefahren wird.
Ohne Intent erstellen (Konfigurations- oder Hardwareänderungen): Stellt Änderungen an der aktuellen Datenbankversion bereit. Zu den Anwendungsfällen gehören das Ändern von Maschinentypen (CPU-/RAM-Skalierung), das Testen von Datenbank-Flags oder das Bewerten von Speicheränderungen ohne Upgrade der Engine-Version.

Funktionsweise von Blau/Grün-Bereitstellungen

Blau/Grün-Bereitstellungen von Cloud SQL bieten einen automatisierten Workflow, bei dem Änderungen in einer temporären sekundären Umgebung bereitgestellt werden, bevor der Live-Traffic umgestellt wird.

Bei einer Blau/Grün-Bereitstellung erstellt Cloud SQL eine separate Staging-Umgebung (grün), die Ihre vorhandene Produktionsumgebung (blau) spiegelt. Der Dienst verwaltet die kontinuierliche logische Replikation von Blau zu Grün. Sie können die Kompatibilität und Leistung der Anwendung in der grünen Umgebung gründlich testen, ohne den Produktionstraffic zu beeinträchtigen. Wenn Sie bereit sind, lösen Sie einen schnellen Wechsel aus, der der grünen Umgebung den Lese- und Schreibstatus für die Produktion mit minimaler Ausfallzeit der Anwendung (normalerweise in Sekunden) zuweist.

Komponenten einer Blau/Grün-Bereitstellung

Ein Blau/Grün-Deployment besteht aus den folgenden Komponenten:

Blaue Umgebung (Quelle): Ihre vorhandene Produktionsumgebung, die aktiv Anwendungstraffic verarbeitet. Sie besteht aus der Quellinstanz für Lese- und Schreibvorgänge und der zugehörigen Konfiguration.
Grüne Umgebung (Ziel): Eine temporäre, isolierte Staging-Umgebung, die von Cloud SQL als Klon der blauen Umgebung erstellt wird. Die grüne Umgebung enthält die von Ihnen angeforderten Änderungen (z. B. eine neuere Datenbankversion) und wird durch kontinuierliche Replikation mit der blauen Umgebung synchronisiert. Cloud SQL benennt die grüne Staging-Instanz automatisch nach dem Muster BLUE_INSTANCE_NAME-green-UNIQUE_ID (wobei BLUE_INSTANCE_NAME auf maximal 48 Zeichen gekürzt wird und UNIQUE_ID eine 8-stellige hexadezimale Kennung ist).
Umstellung: Der geplante, vom Nutzer initiierte Prozess, bei dem die grüne Umgebung in die neue Lese- und Schreibinstanz für die Produktion umgewandelt wird. Während des Switchovers tauscht Cloud SQL die Verbindungsendpunkte aus, sodass Anwendungen mit einem kurzen Verbindungsabbruch (normalerweise in Sekunden) eine Verbindung zur grünen Umgebung herstellen. Die erwartete Ausfallzeit während des Wechsels variiert je nach Cloud SQL-Version:
- Cloud SQL Enterprise Plus-Version: Die Ausfallzeit bei der Umstellung beträgt in der Regel weniger als eine Sekunde.
- Cloud SQL Enterprise-Version: Die Ausfallzeit bei der Umstellung beträgt in der Regel weniger als 60 Sekunden, je nach Arbeitslast und Replikationsverzögerung.
Im Gegensatz zu einem ungeplanten Failover (der bei einem Ausfall automatisch ausgelöst wird) ist ein Switchover ein kontrollierter Vorgang, der für das geplante Änderungsmanagement verwendet wird.
Löschen: Der Prozess, bei dem die Blau/Grün-Bereitstellungsressource entfernt wird. Das Löschverhalten hängt davon ab, ob ein Wechsel stattgefunden hat:
- Vor dem Wechsel: Wenn Sie die Bereitstellung löschen, werden die grüne Staging-Instanz und die Bereitstellungsressource entfernt. Ihre blaue Produktionsinstanz ist davon nicht betroffen und verarbeitet weiterhin Traffic.
- Nach der Umstellung: Durch das Löschen des Deployments werden die Deployment-Metadaten entfernt. Standardmäßig werden sowohl die konvertierte Instanz (grün) als auch die blaue Instanz beibehalten. Sie können die blaue Instanz optional löschen, um laufende Kosten zu vermeiden.

Lebenszyklus und Status von Bereitstellungen

Eine Blau/Grün-Bereitstellung durchläuft vier verschiedene Lebenszyklusphasen:

Erstellung und Staging (PROVISIONING): Wenn Sie ein Blau/Grün-Deployment anfordern, stellt Cloud SQL eine temporäre grüne Zielinstanz bereit, die Ihre blaue Produktionsumgebung klont. Bei einem Upgrade auf eine Hauptversion führt Cloud SQL auch die API für die Vorabprüfung des Upgrades auf eine Hauptversion aus, um die Datenbankkompatibilität zu prüfen, bevor mit dem Upgrade-Workflow fortgefahren wird. Cloud SQL wendet das angeforderte Upgrade oder die Konfigurationsänderung auf die grüne Umgebung an und startet die kontinuierliche logische Replikation von blau zu grün.
Staging-Überprüfung (SWITCHOVER_READY oder SWITCHOVER_NOT_READY): Wenn die Erstreplikation abgeschlossen ist, wechselt das Deployment zu SWITCHOVER_READY (oder SWITCHOVER_NOT_READY, wenn die Replikation fehlerhaft ist oder Fehler auftreten). Die blaue Version verarbeitet weiterhin den Live-Produktionstraffic. Sie stellen eine Verbindung zu „Grün“ her, um Validierungstests auszuführen, die Anwendungskompatibilität zu prüfen und die Abfrageleistung zu testen.
Switchover-Ausführung (SWITCHOVER_IN_PROGRESS oder SWITCHOVER_COMPLETED): Wenn Sie einen Switchover auslösen, führt Cloud SQL Sicherheitsvorabprüfungen durch, tauscht Verbindungsendpunkte aus und legt die grüne Instanz als aktive Produktionsinstanz für Lese- und Schreibvorgänge (SWITCHOVER_COMPLETED) fest. Die blaue Instanz wird in eine eigenständige Instanz für Lese- und Schreibvorgänge umgewandelt. Aktive Lese- und Schreibvorgänge werden ausschließlich an die grüne Instanz weitergeleitet und die logische Replikation von blau zu grün wird beendet. Weitere Informationen finden Sie unter Blau/Grün-Bereitstellungswechsel durchführen.
Löschen (DELETING): Wenn Sie mit dem Testen fertig sind oder die Produktionsvorgänge überprüft haben, löschen Sie die Bereitstellungsressource. Das Löschverhalten hängt vom Bereitstellungsstatus ab:
- Vor der Umstellung (Abbrechen): Wenn Sie sich entscheiden, die Bereitstellung nicht fortzusetzen, oder wenn Probleme bei der Überprüfung auftreten, wird durch das Löschen der Bereitstellung die grüne Staging-Instanz entfernt und die Bereitstellungsmetadaten werden gelöscht. Die ursprüngliche blaue Produktionsinstanz bleibt unverändert und verarbeitet weiterhin ohne Unterbrechung Traffic.
- Nach dem Switchover (Bereinigung): Nach Abschluss des Switchovers und der Überprüfung der Vorgänge auf der neuen Produktionsinstanz werden durch das Löschen des Deployments die Deployment-Metadaten entfernt. Standardmäßig werden sowohl die neue Produktionsinstanz (grün) als auch die blaue Instanz als eigenständige Lese- und Schreibinstanzen beibehalten. Optional können Sie das Flag --delete-old-source angeben, um die blaue Instanz endgültig zu löschen und keine weiteren Kosten dafür zu verursachen.
Weitere Informationen finden Sie unter Blau/Grün-Bereitstellung löschen.

Status von Deployment-Ressourcen

Wenn Sie ein Blau/Grün-Deployment prüfen, wird im Feld state der aktuelle Lebenszyklusstatus angezeigt:

PROVISIONING: Die Bereitstellung wird erstellt. Bei Upgrades von Hauptversionen führt Cloud SQL die Vorabprüfungs-API aus, um die Kompatibilität zu prüfen, bevor der Vorgang fortgesetzt wird. Cloud SQL stellt die grüne Umgebung bereit, wendet die angeforderten Upgrades an und richtet die kontinuierliche logische Replikation ein.
SWITCHOVER_READY: Die grüne Umgebung ist bereitgestellt, die logische Replikation von blau zu grün ist fehlerfrei und die Bereitstellung ist für den Wechsel bereit.
SWITCHOVER_NOT_READY: Die Bereitstellung ist bereitgestellt, aber der Wechsel kann nicht initiiert werden. Dies geschieht, wenn die logische Replikation unterbrochen oder beendet wurde, die erste Replikation nicht abgeschlossen wurde oder bei einem gekoppelten Knoten ein Fehler aufgetreten ist.
SWITCHOVER_IN_PROGRESS: Ein Wechselvorgang wird aktiv ausgeführt. Cloud SQL tauscht die Verbindungsendpunkte aus und wandelt die grüne Instanz in die aktive Produktionsinstanz für Lese- und Schreibvorgänge um.
SWITCHOVER_COMPLETED: Der Wechselvorgang wurde erfolgreich abgeschlossen. Die grüne Instanz ist jetzt Ihre aktive Produktionsinstanz zum Lesen und Schreiben und die blaue Instanz wird als eigenständige Instanz zum Lesen und Schreiben beibehalten.
DELETING: Das Deployment wird gelöscht. Wenn Sie die Instanz vor der Umstellung löschen, entfernt Cloud SQL die grüne Staging-Instanz und löscht die Bereitstellungsmetadaten. Wenn Sie die Bereitstellung nach dem Wechsel löschen, entfernt Cloud SQL die Bereitstellungsmetadaten und löscht optional die blaue Instanz, wenn das Flag --delete-old-source angegeben ist.
STATE_UNSPECIFIED: Der Status der Bereitstellung ist unbekannt.

Wechselstatus und -bereitschaft

Die Bereitschaft für einen Switchover hängt vom Replikationszustand und vom Knotenstatus ab, um Ihre Produktionsdatenbank vor Datenverlust oder längeren Ausfallzeiten zu schützen:

Replikationszustand und -verzögerung: Wenn die logische Replikation zwischen Blau und Grün unterbrochen, pausiert oder fehlgeschlagen ist, wechselt der Bereitstellungsstatus zu SWITCHOVER_NOT_READY. In der Bereitstellung state und der Ausgabe von „describe“ wird keine Replikationsverzögerung gemeldet. Cloud SQL wertet die Replikationsverzögerung auch nicht als Vorabprüfung aus, wenn der Bereitstellungsstatus ermittelt wird. Der Umschaltvorgang schlägt jedoch fehl, wenn die Replikationsverzögerung beim Initiieren des Umschaltvorgangs zu hoch ist. Damit die Umstellung erfolgreich ist, sollte die Replikationsverzögerung vor dem Start der Umstellung minimal sein. Sie können die Replikationsverzögerung in Cloud Monitoring überwachen, indem Sie Messwerte wie replica_lag in der Cloud SQL-Messwertliste prüfen, oder direkt auf der grünen Instanz. Weitere Informationen finden Sie unter Replikationsverzögerung überwachen.
Status des gekoppelten Knotens: Unter deploymentMappings meldet jeder gekoppelte Knoten seinen eigenen Knotenstatus (z. B. PROVISIONED, UPGRADED, UPGRADE_FAILED, SWITCHOVER_IN_PROGRESS, SWITCHOVER_SUCCEEDED oder SWITCHOVER_FAILED). Wenn bei einem gekoppelten Knoten ein Fehler auftritt (UPGRADE_FAILED oder SWITCHOVER_FAILED), wechselt der Gesamtstatus der Bereitstellung zu SWITCHOVER_NOT_READY. Wenn ein Wechsel fehlschlägt, bleibt das Routing auf der blauen Instanz, ohne dass Daten verloren gehen.
Fehlerbehebung bei der Bereitschaft für den Switchover: Wenn Ihre Bereitstellung SWITCHOVER_NOT_READY meldet, prüfen Sie das Feld errorDetail, um Replikations- oder Knotenfehler zu diagnostizieren. Prüfen Sie vor dem Starten des Switchovers, ob die Replikationsverzögerung minimal ist und ob aktive Batch-DDL-Vorgänge oder lang andauernde Schreibtransaktionen auf der blauen Instanz abgeschlossen sind.

Beschränkungen

Beachten Sie die folgenden Einschränkungen, bevor Sie Blau/Grün-Bereitstellungen verwenden:

Unterstützte Engines und Versionen: Cloud SQL for MySQL-Instanzen mit MySQL 5.7 und höher werden für die Konfigurations-Staging-Umgebung (Erstellen ohne Absicht) unterstützt. Ziele für Hauptversionsupgrades (Erstellung mit Absicht) werden von MySQL 8.0 bis 8.4 unterstützt. MySQL 8.0.18 wird für Blau/Grün-Bereitstellungen nicht unterstützt.
Nicht unterstützte Datenbank-Engines: Cloud SQL for PostgreSQL und Cloud SQL for SQL Server werden nicht unterstützt.
Instanzen mit Lesereplikaten: Blau/Grün-Bereitstellungen unterstützen keine Instanzen mit Lesereplikaten.
Nicht unterstützte Netzwerkkonfigurationen: Blau/Grün-Bereitstellungen unterstützen keine ausgehenden Private Service Connect-Konfigurationen.
IAM-Gruppenauthentifizierung: Blau/Grün-Bereitstellungen sind nicht mit der IAM-Gruppenauthentifizierung von MySQL kompatibel und können zu Fehlern bei der Umstellung führen.
Anforderung an die Netzwerkarchitektur: Cloud SQL-Instanzen müssen die neue Netzwerkarchitektur verwenden. Instanzen, die die alte Netzwerkarchitektur verwenden, werden nicht unterstützt.
Anforderung für binäres Logging: Für MySQL-Instanzen müssen automatische Sicherungen und binäres Logging aktiviert sein, um die kontinuierliche logische Replikation in die grüne Umgebung zu unterstützen.
Anforderung an die Wartungsversion: Auf der blauen Quellinstanz muss die neueste Wartungsversion ausgeführt werden, bevor Sie ein Blau/Grün-Deployment erstellen. Informationen zum Prüfen oder Aktualisieren der Wartungsversion Ihrer Instanz finden Sie unter Selfservice-Wartung durchführen.
Ressourcenverfügbarkeit: Die Instanzbereitstellung während Blau/Grün-Bereitstellungsworkflows, einschließlich der Erstellung der grünen Staging-Instanz und der Erstellung der blauen Instanz nach der Umstellung, kann durch Einschränkungen der Rechenressourcen in der ausgewählten Region oder Zone beeinträchtigt werden.
Ungeplante Ausfälle und Failover: Der Wechsel zur Blau/Grün-Bereitstellung ist ein geplanter Vorgang, für den eine fehlerfreie blaue RUNNING-Quellinstanz erforderlich ist. Die grüne Staging-Instanz fungiert als spezielles Lesereplikat. Wie Standard-Lesereplikate kann die grüne Instanz bei einem ungeplanten Ausfall der Quellinstanz nicht als Failover-Ziel verwendet werden. Konfigurieren Sie Ihre Instanz für die Hochverfügbarkeit oder verwenden Sie ein Replikat für die Notfallwiederherstellung, um die automatisierte Wiederherstellung nach einem Ausfall zu ermöglichen.

Abrechnung und Preise

Für die Verwendung von Blau/Grün-Bereitstellungen fallen keine zusätzlichen Kosten an. Da während der Bereitstellung jedoch eine vollständige parallele grüne Umgebung bereitgestellt wird, werden Ihnen für die gesamte Dauer, in der beide Umgebungen vorhanden sind, die Standardtarife für die blaue und die grüne Instanz in Rechnung gestellt.

Löschen Sie die Bereitstellung und die zugehörigen Instanzen, um unnötige Kosten zu vermeiden:

Vor der Umstellung: Wenn Sie die Bereitstellung abbrechen, löschen Sie die Bereitstellung, um die grüne Staging-Instanz zu entfernen und die Gebühren dafür zu beenden.
Nach der Umstellung: Löschen Sie das Deployment und geben Sie das Flag --delete-old-source an, um die blaue Instanz dauerhaft zu löschen, nachdem Sie die neue Produktionsinstanz überprüft haben. Wenn Sie die blaue Instanz nicht löschen, werden Ihnen weiterhin beide Instanzen in Rechnung gestellt.