Direkte Datenbankaktualisierung durchführen

Auf dieser Seite wird beschrieben, wie Sie die Hauptversion der Datenbank aktualisieren, indem Sie Ihre Cloud SQL-Instanz direkt aktualisieren, anstatt Daten zu migrieren.

Einführung

Anbieter von Datenbanksoftware veröffentlichen regelmäßig neue Hauptversionen, die neue Features, Leistungsverbesserungen und Sicherheitsverbesserungen enthalten. Cloud SQL übernimmt neue Versionen nach der Veröffentlichung. Sobald Cloud SQL Unterstützung für eine neue Hauptversion bietet, können Sie ein Upgrade Ihrer Instanzen durchführen, um die Datenbank auf dem neuesten Stand zu halten.

Sie können die Datenbankversion einer Instanz direkt aktualisieren oder Daten migrieren. Direkte Upgrades sind eine einfache Möglichkeit, ein Upgrade der Hauptversion einer Instanz durchzuführen. Sie müssen keine Daten migrieren oder Anwendungsverbindungsstrings ändern. Bei direkten Upgrades können Sie den Namen, die IP-Adresse und andere Einstellungen Ihrer aktuellen Instanz nach dem Upgrade beibehalten. Für direkte Upgrades ist es nicht erforderlich, Datendateien zu verschieben, und sie können schneller ausgeführt werden. In einigen Fällen ist die Ausfallzeit kürzer als bei der Migration Ihrer Daten.

Beim Cloud SQL-Vorgang für das direkte Upgrade von MySQL wird das Dienstprogramm mysql_upgrade verwendet.

Upgrade einer Hauptversion planen

  1. Wählen Sie eine Ziel-Hauptversion aus.

    Liste der von Cloud SQL unterstützten Versionen.

  2. Berücksichtigen Sie die in den einzelnen Datenbankversionen verfügbaren Versions- und Adressinkompatibilitäten.

    Neue Hauptversionen führen inkompatible Änderungen ein, sodass Sie möglicherweise den Anwendungscode, das Schema oder die Datenbankeinstellungen ändern müssen. Bevor Sie ein Upgrade für Ihre Datenbankinstanz durchführen, lesen Sie die Versionshinweise Ihrer Zielhauptversion, um zu ermitteln, welche Inkompatibilitäten berücksichtigt werden müssen.

    Nach dem Upgrade auf eine neuere Version kann sich der Standardwert einiger Systemvariablen ändern. Der Standardwert für character_set_server in MySQL 5.6 und MySQL 5.7 ist beispielsweise utf8. Wenn Sie ein Upgrade auf MySQL 8.0 durchführen, ändert sich der Standardwert von character_set_server in utf8mb4. Wenn Sie utf8 wiederherstellen möchten, müssen Sie den Wert des Datenbank-Flags manuell in den vorherigen Wert ändern. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren. Die meisten Änderungen am Standardwert werden von der MySQL-Community übernommen (siehe Standardeinstellungen für Server aktualisieren).

  3. Prüfen Sie vorab, ob Upgrades von MySQL 5.7 auf 8.0 vorhanden sind.

    Führen Sie eine Vorabprüfung aus, bevor Sie Upgrades von MySQL 5.7 auf 8.0 ausführen. Dafür steht Ihnen die Upgrade Checker Utility in MySQL Shell zur Verfügung. Wenn bei der Vorabprüfung Probleme ermittelt werden, beheben Sie diese, bevor Sie mit dem Upgrade fortfahren. Mit Cloud SQL wird beim Upgrade von Hauptversionen keine Vorabprüfung ausgeführt. Das Aktualisieren einer Instanz, für die eine Vorabprüfung fehlgeschlagen ist, kann ebenfalls fehlschlagen.

  4. Prüfen Sie den Speicherplatz und die Maschinentypen der Instanz.

    Das Upgrade einer Hauptversion erfordert zusätzliche Ressourcen wie z. B. zusätzlichen Speicherplatz, um aktualisierte Tabellen zu speichern. Wenn der Speicherplatz nicht ausreicht, schlägt das Upgrade fehl und wird rückgängig gemacht. Für ein Upgrade von MySQL 5.7 auf 8.0 ist zusätzlicher Arbeitsspeicher erforderlich, um alte Metadaten in das neue Datenwörterbuch zu konvertieren. Sorgen Sie vor dem Ausführen eines Upgrades der Hauptversion dafür, dass jeder Tabelle mehr als 100 KB Arbeitsspeicher zur Verfügung steht. Sie können den Arbeitsspeicher auch vorübergehend erhöhen und dafür den Maschinentyp ändern.

  5. Auf Änderungen an Nutzerzuweisungen in MySQL 8.0 prüfen

    Cloud SQL for MySQL Version 8.0 verwendet ein Flag namens partial_revokes, das standardmäßig auf ON gesetzt ist. Anders als bei MySQL 5.7 ist bei diesem Flag die Verwendung von Platzhalterzeichen in Datenbankbefehlen vom Typ GRANT nicht mehr möglich. Ändern Sie vor dem Upgrade auf MySQL 8.0 die Datenbanknutzerberechtigungen, um zu gewährleisten, dass Datenbanknutzer Zugriff auf die richtigen Datenbankschemas haben. Aktualisieren Sie die Berechtigungen des Nutzers, um den vollständigen Namen der erforderlichen Datenbankschemas zu verwenden, anstatt Platzhalterzeichen zu verwenden.

    Weitere Informationen zur Funktionsweise dieses Flags in MySQL 8.0 finden Sie unter partial_revokes in MySQL 8.0.

  6. Testen Sie das Upgrade im Probelauf.

    Führen Sie einen Probelauf des End-to-End-Upgradeprozesses in einer Testumgebung durch, bevor Sie die Produktionsdatenbank aktualisieren. Sie können Ihre Instanz klonen, um eine identische Kopie der Daten zu erstellen, bei denen Sie den Upgradeprozess testen können.

    Überprüfen Sie nicht nur, ob das Upgrade erfolgreich abgeschlossen wurde, sondern führen Sie auch Tests durch, um sicherzustellen, dass sich die Anwendung auf der aktualisierten Datenbank wie erwartet verhält.

  7. Legen Sie einen Zeitpunkt für das Upgrade fest.

    Für ein Upgrade darf die Instanz für einen bestimmten Zeitraum nicht verfügbar sein. Planen Sie das Upgrade in einem Zeitraum niedriger Datenbankaktivität.

Upgrade auf eine Hauptversion vorbereiten

Führen Sie vor dem Upgrade die folgenden Schritte aus:

  1. NUR für Upgrades von MySQL 5.7 auf 8.0: Prüfen und beheben Sie inkompatible Probleme, die bei der Vorprüfung gefunden wurden. Häufige Probleme:

    1. Hinzufügen neuer reservierter Keywords, z. B. RANKS, GROUPS, FUNCTION in gespeicherten Prozeduren, Triggern usw. Weitere Informationen finden Sie unter Keywords und reservierte Wörter.
    2. Ungültige UTF-Zeichen in Tabellendefinitionen.
    3. Nicht zugesicherte XA-Übergänge, die per Commit (mit der XA COMMIT-Anweisung) oder per Rollback (mit der XA ROLLBACK-Anweisung) durchgeführt werden müssen.
    4. Fremdschlüsseleinschränkung in Namen mit mehr als 64 Zeichen.
    5. Räumlicher Datentyp im Mix-Index von Spalten. Weitere Informationen finden Sie unter Räumliche Datentypen.

    Weitere Informationen finden Sie unter Installation auf das Upgrade vorbereiten und Upgrade auf MySQL 8.0 ausführen.

  2. Speicherplatz und Maschinentyp der Instanz prüfen

    Upgrades von Hauptversionen benötigen zusätzlichen Speicherplatz und Arbeitsspeicher, um die aktualisierten Tabellen und das neue Datenwörterbuch zu speichern. Wenn nicht genügend Speicherplatz vorhanden ist, schlägt das Upgrade fehl und wird auf die ursprüngliche Version zurückgesetzt. Cloud SQL empfiehlt für jede Tabelle mindestens 100 KB Arbeitsspeicher.

    Hinweis: Sie können den Arbeitsspeicher vorübergehend erhöhen, indem Sie den Maschinentyp ändern, bevor Sie das Upgrade der Hauptversion ausführen. Weitere Informationen finden Sie unter Maschinentyp ändern.

  3. Aktualisieren Sie Ihre Lesereplikate.

    Wenn Sie Lesereplikate verwenden, müssen Sie zuerst alle Lesereplikate aktualisieren, bevor Sie die primäre Instanz aktualisieren. Wenn für das Replikat ein Upgrade durchgeführt wird, für die primäre Instanz jedoch nicht, kann die Replikation fehlschlagen, wenn in der primären Instanz Anweisungen oder Funktionen verwendet werden, die in einer vom Replikat verwendeten höheren MySQL-Version nicht mehr unterstützt werden. Zur Vermeidung solcher Probleme empfiehlt Cloud SQL:

    1. Führen Sie unmittelbar nach dem Upgrade der Replikate ein Upgrade der primären Instanz durch.
    2. Führen Sie keine Abfragen aus, die mit der neuen Version auf der primären Instanz nicht kompatibel sind, bis das Upgrade erfolgreich abgeschlossen wurde.
    3. (Optional) Pausieren Sie alle WRITE-Anweisungen an die primäre Instanz, bis das Upgrade erfolgreich abgeschlossen wurde.
    4. (Optional) Entfernen Sie alle Replikate, bevor Sie die primäre Instanz upgraden, und erstellen Sie die Replikate neu, sobald das Upgrade abgeschlossen ist.

    Wenn die Replikation unterbrochen wird, wird das Replikat auf die Version der primären Instanz zurückgesetzt. Sie können das Replikat noch einmal aktualisieren. Wenn das Problem jedoch weiterhin besteht, lesen Sie [FAQ](#faqs).

Direkte Datenbankaktualisierung durchführen

Wenn Sie einen Upgradevorgang starten, prüft Cloud SQL zuerst die Konfiguration Ihrer Instanz dahingehend, ob sie für ein Upgrade kompatibel ist. Nach der Prüfung der Konfiguration deaktiviert Cloud SQL Ihre Instanz, erstellt eine Sicherung vor dem Upgrade, führt das Upgrade durch, aktiviert Ihre Instanz und erstellt eine Sicherung nach dem Upgrade.

Wenn Sie ein Upgrade auf MySQL 8.0 ausführen, wird Ihre Instanz von Cloud SQL automatisch in der Standard-Nebenversion bereitgestellt.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
  3. Klicken Sie auf Bearbeiten.
  4. Klicken Sie im Abschnitt Instanzinformationen auf die Schaltfläche Upgrade und bestätigen Sie, dass Sie die Seite "Upgrade" aufrufen möchten.
  5. Klicken Sie auf der Seite Datenbankversion auswählen auf die Liste Datenbankversion für Upgrade und wählen Sie eine der verfügbaren Hauptversionen der Datenbank aus.
  6. Klicken Sie auf Weiter.
  7. Geben Sie im Feld Instanz-ID den Namen der Instanz ein und klicken Sie dann auf die Schaltfläche Upgrade starten.
Der Vorgang kann mehrere Minuten dauern.

Prüfen Sie, ob die Hauptversion der aktualisierten Datenbank unter dem Instanznamen auf der Seite Übersicht der Instanz angezeigt wird.

gcloud

  1. Starten Sie das Upgrade.

    Führen Sie den Befehl gcloud sql instances patch mit dem Flag --database-version aus.

    Ersetzen Sie vor dem Ausführen des Befehls Folgendes:

    • INSTANCE_NAME: Name der Instanz
    • DATABASE_VERSION: Der Enum für die Hauptversion der Datenbank, die größer als die aktuelle Version sein muss. Siehe die verfügbaren Datenbankversions-Enums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Upgrades von Hauptversionen dauern einige Minuten. Möglicherweise wird eine Meldung angezeigt, die angibt, dass der Vorgang länger als erwartet dauert. Sie können diese Nachricht entweder ignorieren oder den Befehl gcloud sql operations wait ausführen, um sie zu verwerfen.

  2. Rufen Sie den Namen des Upgradevorgangs ab.

    Führen Sie den Befehl gcloud sql operations list mit dem Flag --instance aus.

    Bevor Sie den Befehl ausführen, ersetzen Sie die Variable INSTANCE_NAME durch den Namen der Instanz. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Überwachen Sie den Status des Upgrades.

    Führen Sie folgenden Befehl gcloud sql operations describe aus.

    Bevor Sie den Befehl ausführen, ersetzen Sie die Variable OPERATION durch den Namen des Upgradevorgangs, der im vorherigen Schritt abgerufen wurde. 

    gcloud sql operations describe OPERATION

REST Version 1

  1. Starten Sie das direkte Upgrade.

    Verwenden Sie eine PATCH-Anfrage mit der Methode instances:patch.

    Ersetzen Sie diese Variablen, bevor Sie die Anfragedaten verwenden:

    • project_id: ID des Projekts
    • instance_name: Name der Instanz

    HTTP-Methode und URL:

    POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance_name

    JSON-Text anfordern:

    {
  "databaseVersion": enum DATABASE_VERSION
}

    Ersetzen Sie DATABASE_VERSION durch den Enum der Hauptversion der Datenbank. Dieser muss größer als die aktuelle Version sein. Siehe die verfügbaren Datenbankversions-Enums.

    Senden Sie Ihre Anfrage mit curl oder PowerShell. Siehe Instanzen bearbeiten.

  2. Rufen Sie den Namen des Upgradevorgangs ab.

    Verwenden Sie eine GET-Anfrage mit der Methode operations.list, nachdem Sie project_id durch die ID des Projekts ersetzt haben.

    HTTP-Methode und URL:

    GET https://sqladmin.googleapis.com/v1/projects/project-id/operations

  3. Überwachen Sie den Status des Upgrades.

    Verwenden Sie eine GET-Anfrage mit der Methode operations.get, nachdem Sie die folgenden Variablen ersetzt haben:

    • project_id: ID des Projekts
    • operation_name: Der Name des Upgradevorgangs, der im vorherigen Schritt abgerufen wurde.

    HTTP-Methode und URL:

    GET https://sqladmin.googleapis.com/v1/projects/project-id/operation/operation_name

Terraform

Verwenden Sie zum Aktualisieren der Version der Datenbank eine Terraform-Ressource und den Terraform-Anbieter für Google Cloud, Version 4.34.0 oder höher.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Änderungen anwenden

Führen Sie die Schritte in den folgenden Abschnitten aus, um Ihre Terraform-Konfiguration auf ein Google Cloud-Projekt anzuwenden.

Cloud Shell vorbereiten

  1. Rufen Sie Cloud Shell auf.

  2. Legen Sie das Google Cloud-Standardprojekt fest, auf das Sie Ihre Terraform-Konfigurationen anwenden möchten.

    Sie müssen diesen Befehl nur einmal pro Projekt und in jedem beliebigen Verzeichnis ausführen.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Umgebungsvariablen werden überschrieben, wenn Sie in der Terraform-Konfigurationsdatei explizite Werte festlegen.

Verzeichnis vorbereiten

Jede Terraform-Konfigurationsdatei muss ein eigenes Verzeichnis haben (auch als Stammmodul bezeichnet).

  1. Erstellen Sie in Cloud Shell ein Verzeichnis und eine neue Datei in diesem Verzeichnis. Der Dateiname muss die Erweiterung .tf haben, z. B. main.tf. In dieser Anleitung wird die Datei als main.tf bezeichnet. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Wenn Sie einer Anleitung folgen, können Sie den Beispielcode in jedem Abschnitt oder Schritt kopieren.

    Kopieren Sie den Beispielcode in das neu erstellte main.tf.

    Kopieren Sie optional den Code aus GitHub. Dies wird empfohlen, wenn das Terraform-Snippet Teil einer End-to-End-Lösung ist.

  3. Prüfen und ändern Sie die Beispielparameter, die auf Ihre Umgebung angewendet werden sollen.
  4. Speichern Sie die Änderungen.
  5. Initialisieren Sie Terraform. Dies ist nur einmal für jedes Verzeichnis erforderlich. 
    terraform init

    Fügen Sie optional die Option -upgrade ein, um die neueste Google-Anbieterversion zu verwenden: 

    terraform init -upgrade

Änderungen anwenden

  1. Prüfen Sie die Konfiguration und prüfen Sie, ob die Ressourcen, die Terraform erstellen oder aktualisieren wird, Ihren Erwartungen entsprechen: 
    terraform plan

    Korrigieren Sie die Konfiguration nach Bedarf.

  2. Wenden Sie die Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

    Warten Sie, bis Terraform die Meldung „Apply complete“ anzeigt.

  3. Öffnen Sie Ihr Google Cloud-Projekt, um die Ergebnisse aufzurufen. Rufen Sie in der Google Cloud Console Ihre Ressourcen in der Benutzeroberfläche auf, um sicherzustellen, dass Terraform sie erstellt oder aktualisiert hat.

Änderungen löschen

So löschen Sie das Projekt:

  1. Um den Löschschutz zu deaktivieren, setzen Sie in der Terraform-Konfigurationsdatei das Argument deletion_protection auf false. 
    deletion_protection =  "false"
  2. Wenden Sie die aktualisierte Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

  1. Entfernen Sie Ressourcen, die zuvor mit Ihrer Terraform-Konfiguration angewendet wurden, indem Sie den folgenden Befehl ausführen und yes an der Eingabeaufforderung eingeben:

    terraform destroy

Wenn Sie eine direkte Upgradeanfrage stellen, führt Cloud SQL zuerst eine Prüfung vor dem Upgrade durch. Wenn Cloud SQL feststellt, dass die Instanz nicht für ein Upgrade bereit ist, schlägt die Upgradeanfrage mit einer Meldung dazu fehl, wie Sie das Problem beheben können. Weitere Informationen finden Sie unter Fehlerbehebung bei einem Hauptversionsupgrade.

Automatische Upgradesicherungen

Wenn Sie ein Upgrade der Hauptversion durchführen, erstellt Cloud SQL automatisch zwei On-Demand-Sicherungen, die als Upgradesicherungen bezeichnet werden:

  • Die erste Upgradesicherung ist die Sicherung vor dem Upgrade, die unmittelbar vor Beginn des Upgrades durchgeführt wird. Mit dieser Sicherung können Sie Ihre Datenbankinstanz auf den Zustand der vorherigen Version zurücksetzen.
  • Die zweite Upgrade-Sicherung ist die Sicherung nach dem Upgrade, die sofort erfolgt, nachdem neue Schreibvorgänge auf die aktualisierte Datenbankinstanz zugelassen wurden.

Wenn Sie die Liste Ihrer Sicherungen aufrufen, werden die Upgradesicherungen vom Typ On-demand aufgelistet. Upgrade-Sicherungen sind mit Labels versehen, damit Sie sie leicht identifizieren können. Wenn Sie beispielsweise ein Upgrade von MySQL 5.7 auf MySQL 8.0 ausführen, ist die Sicherung vor dem Upgrade mit Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. und die Sicherung nach dem Upgrade mit Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7. gekennzeichnet.

Wie bei anderen On-Demand-Sicherungen bleiben Upgradesicherungen erhalten, bis Sie sie löschen oder die Instanz löschen. Wenn Sie PITR aktiviert haben, können Sie Ihre Upgradesicherungen nicht löschen, solange diese sich in Ihrem Zeitfenster für die Aufbewahrung befinden. Wenn Sie Ihre Upgradesicherungen löschen möchten, müssen Sie PITR deaktivieren oder warten, bis sich die Upgradesicherungen nicht mehr im Aufbewahrungsfenster befinden.

Upgrade der Hauptversion abschließen

Führen Sie nach dem Upgrade der primären Instanz die folgenden Schritte aus, um das Upgrade abzuschließen:

  1. Führen Sie Akzeptanztests durch.

    Führen Sie Tests durch, um zu prüfen, ob das aktualisierte System wie erwartet funktioniert.

  2. Optional: Aktualisieren Sie die Nutzerberechtigungen.

    Nach dem Upgrade auf MySQL 8.0 hat MySQL die Sicherheits- und Kontoverwaltungssysteme geändert. Weitere Informationen finden Sie unter Das ist neu in MySQL 8.0.

    Dies kann dazu führen, dass Nutzer, die in der MySQL-Version 5.7 der Instanz erstellt wurden, nicht die gleichen Berechtigungen haben wie Nutzer, die direkt in MySQL 8.0 erstellt wurden. Ein Nutzer, der von MySQL 5.7 aktualisiert wird, hat beispielsweise nicht die Berechtigungen CREATE ROLE und DROP ROLE, da diese Berechtigungen in MySQL 5.7 nicht vorhanden waren. Cloud SQL empfiehlt, dass Sie nach einem Upgrade von Versionen die Nutzerberechtigungen zurücksetzen, um Probleme mit Nutzerberechtigungen zu beheben.

    So setzen Sie Nutzerberechtigungen zurück:

    1. Erstellen Sie einen Nutzer mit der zugewiesenen Rolle cloudsqlsuperuser.

    2. Verwenden Sie den erstellten Nutzer, um alle vorherigen Berechtigungen eines aktualisierten Nutzers zu widerrufen mit:

      REVOKE ALL PRIVILEGES ON *.* FROM user@host

    3. Gewähren Sie dem aktualisierten Nutzer die erwarteten Berechtigungen.

  3. (Optional) Erstellen Sie eine Sicherung.

    Obwohl Cloud SQL nach dem Upgrade der primären Instanz automatisch eine Sicherung erstellt, empfiehlt Cloud SQL, selbst eine Sicherung zu erstellen, damit Sie Ihre Datenbank bei Bedarf wiederherstellen können.

Fehlerbehebung bei einem Upgrade einer Hauptversion

Cloud SQL gibt eine Fehlermeldung zurück, wenn Sie einen ungültigen Upgrade-Befehl ausführen, z. B. wenn Ihre Instanz ungültige Datenbank-Flags für die neue Version enthält.

Wenn Ihre Upgradeanfrage fehlschlägt, überprüfen Sie die Syntax der Upgradeanfrage. Wenn die Anfrage eine gültige Struktur hat, prüfen Sie die folgenden Vorschläge.

Upgradelogs ansehen

Wenn bei einer gültigen Upgradeanfrage Probleme auftreten, veröffentlicht Cloud SQL Fehlerlogs in projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err. Jeder Logeintrag enthält ein Label mit der Instanzkennung, damit Sie die Instanz mit dem Upgradefehler identifizieren können. Suchen Sie nach solchen Upgradefehlern und beheben Sie sie.

So rufen Sie Fehlerlogs auf:

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.

  3. Klicken Sie auf der Seite Übersicht der Instanz im Bereich Vorgänge und Logs auf den Link MySQL-Fehlerlogs aufrufen.

    Die Seite Log-Explorer wird geöffnet.

  4. So rufen Sie Logs auf:

    • Wählen Sie den Lognamen im Logfilter Logname aus, um alle Fehlerlogs in einem Projekt aufzulisten.

    Weitere Informationen zu Abfragefiltern finden Sie unter Erweiterte Abfragen.

    • Um die Upgradefehlerlogs für eine einzelne Instanz zu filtern, geben Sie die folgende Abfrage in das Feld In allen Feldern suchen ein, nachdem Sie DATABASE_ID

    durch die Projekt-ID ersetzt haben, gefolgt vom Instanznamen im folgenden Format: project_id:instance_name.

    resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

    Verwenden Sie beispielsweise den folgenden Abfragefilter, um die Upgradefehlerlogs nach einer Instanz namens shopping-db zu filtern, die im Projekt buylots ausgeführt wird:

     resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

Wiederherstellung der vorherigen Hauptversion

Wenn das aktualisierte Datenbanksystem nicht wie erwartet funktioniert, müssen Sie die Instanz möglicherweise in der vorherigen Version wiederherstellen. Dazu stellen Sie die Sicherung vor dem Upgrade in einer Cloud SQL-Wiederherstellungsinstanz wieder her. Dabei handelt es sich um eine neue Instanz, auf der die Version vor dem Upgrade ausgeführt wird.

Gehen Sie so vor, um die vorherige Version wiederherzustellen:

  1. Ermitteln Sie die Sicherung vor dem Upgrade.

    Siehe Automatische Upgradesicherungen.

  2. Erstellen Sie eine Wiederherstellungsinstanz.

    Erstellen Sie eine neue Cloud SQL-Instanz mithilfe der Hauptversion, die Cloud SQL beim Erstellen der Sicherung vor dem Upgrade ausgeführt hat. Legen Sie dieselben Flags und Instanzeinstellungen fest wie für die ursprüngliche Instanz.

  3. Stellen Sie die Sicherung vor dem Upgrade wieder her.

    Stellen Sie die Sicherung vor dem Upgrade auf der Wiederherstellungsinstanz wieder her. Die Ausführung dieses Befehls kann mehrere Minuten dauern.

  4. Fügen Sie die Lesereplikate hinzu.

    Wenn Sie Lesereplikate verwendet haben, fügen Sie sie einzeln hinzu.

  5. Verbinden Sie Ihre Anwendung.

    Nachdem Sie das Datenbanksystem wiederhergestellt haben, aktualisieren Sie Ihre Anwendung mit Details über die Wiederherstellungsinstanz und die zugehörigen Lesereplikate. Sie können die Verarbeitung des Traffics in der Version der Datenbank vor dem Upgrade fortsetzen.

Beschränkungen

In diesem Abschnitt werden die Einschränkungen für das direkte Upgrade der Hauptversion aufgeführt.

  • Sie können kein direktes Upgrade der Hauptversion auf einem externen Replikat durchführen.
  • Das Upgrade von Instanzen von MySQL 5.7 auf 8.0 mit mehr als 512.000 Tabellen kann lange dauern und eine Zeitüberschreitung verursachen.

Häufig gestellte Fragen

Bei der Aktualisierung der Hauptversion der Datenbank können die folgenden Fragen auftreten.

Ist meine Instanz während eines Upgrades nicht verfügbar?
Ja. Die Instanz ist für einen bestimmten Zeitraum nicht verfügbar, während Cloud SQL das Upgrade durchführt.
Wie lange dauert ein Upgrade?

Das Upgrade einer einzelnen Instanz dauert in der Regel weniger als 10 Minuten. Wenn Ihre Instanzkonfiguration eine kleine Menge von vCPUs oder Arbeitsspeicher verwendet, kann Ihr Upgrade mehr Zeit in Anspruch nehmen.

Wenn Ihre Instanz zu viele Datenbanken oder Tabellen hostet oder Ihre Datenbanken sehr groß sind, kann das Upgrade Stunden oder sogar eine Zeitüberschreitung verursachen, da die Upgradezeit der Anzahl der Objekte in Ihren Datenbanken entspricht. Wenn Sie mehrere Instanzen aktualisieren müssen, wird die Gesamtupgradedauer proportional erhöht.

Kann ich die einzelnen Schritte in meinem Upgrade-Prozess überwachen?
Mit Cloud SQL können Sie zwar beobachten, ob ein Upgradevorgang noch läuft, Sie können jedoch nicht die einzelnen Schritte in jedem Upgrade verfolgen.
Kann ich mein Upgrade nach dem Start abbrechen?
Nein, Sie können ein Upgrade nicht mehr abbrechen, nachdem es gestartet wurde. Wenn Ihr Upgrade fehlschlägt, stellt Cloud SQL Ihre Instanz automatisch mit der vorherigen Version wieder her.
Was geschieht mit meinen Einstellungen während eines Upgrades?

Wenn Sie ein direktes Upgrade der Hauptversion durchführen, behält Cloud SQL Ihre Datenbankeinstellungen bei, einschließlich Instanzname, IP-Adresse, explizit konfigurierte Flag-Werte und Nutzerdaten bei. Der Standardwert der Systemvariablen kann sich jedoch ändern. Der Standardwert des Flags character_set_server in MySQL 5.7 ist beispielsweise utf8. Wenn Sie ein Upgrade auf MySQL 8.0 durchführen, ändert sich der Standardwert des Flags in utf8mb4. Wenn Sie den Wert auf utf8 zurücksetzen möchten, setzen Sie den Wert des Flags auf den vorherigen Wert zurück.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren. Wenn ein bestimmtes Flag oder ein Wert in Ihrer Zielversion nicht mehr unterstützt wird, entfernt Cloud SQL das Flag während des Upgrades automatisch.

Was kann ich tun, wenn die Replikation nach dem Upgrade des Replikats unterbrochen wird?
Wenn die Replikation nach dem Upgrade des Replikats unterbrochen wird, wird sie per Rollback auf die MySQL-Version der primären Instanz zurückgesetzt. Sie können das Replikat noch einmal aktualisieren. Wenn das Problem jedoch weiterhin besteht, kann die Replikation wieder fehlschlagen.

Wenn für das Replikat kein Rollback durchgeführt wird, haben Sie zwei Möglichkeiten:

  1. Löschen Sie das fehlerhafte Replikat, erstellen Sie ein neues und führen Sie ein Upgrade für das neue Replikat aus.

    Wenn das Upgrade erneut fehlschlägt, liegt dies wahrscheinlich an inkompatiblen Änderungen, die bei der Aktualisierung des primären Systems vorgenommen wurden. Versuchen Sie, das Problem zu lokalisieren, die primäre Instanz zu reparieren und das Replikat zu aktualisieren. Weitere Informationen finden Sie unter Fehlerbehebung.

  2. Upgrade der primären Instanz durchführen

    Beim Upgradevorgang der primären Instanz werden die Replikate neu erstellt, wenn der Replikat-Thread nicht funktioniert.

Warum wurde für mein aktualisiertes Replikat ein Rollback auf die alte Version durchgeführt?

Wenn ein Upgrade fehlschlägt, wird das Replikat auf die Version der primären Instanz zurückgesetzt. Sie können das Replikat noch einmal upgraden. Wenn das Problem weiterhin besteht, können Sie anhand des mysql.err-Logs für das Replikat die Ursache ermitteln. Suchen Sie nach Suchbegriffen wie [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

Wenn die Fehlermeldung Access denied for AuthId.... mit Änderungen der Nutzerberechtigungen enthält, wird wahrscheinlich eine Abfrage mit MySQL 5.7-Nutzerberechtigungen für mysql- und Systemschemas ausgeführt. Außerdem kann die Abfrage aufgrund der Änderungen an den Sicherheits- und Kontoverwaltungssystemen in MySQL 8.0 fehlschlagen. Um dieses Problem zu beheben, müssen Sie die Abfragen auf der primären Instanz beenden, bevor Sie die primäre Instanz auf die neue Version aktualisieren, und dann das Replikatupgrade wiederholen. Cloud SQL empfiehlt, diese Abfragen in der primären Instanz vorübergehend zu beenden, bevor Sie ein Upgrade auf die neue Version durchführen, da dies zu einem ähnlichen Problem führen kann.

Wenn Sie die Fehlerursache nicht sehen, z. B. Access denied for AuthID.... in den MySQL-Logs, wird Ihr Problem wahrscheinlich durch neue inkompatible Daten verursacht, die der primären Instanz nach dem Upgrade des Replikats möglicherweise hinzugefügt wurden. Lesen Sie die Informationen unter Upgrade auf eine Hauptversion vorbereiten, um Inkompatibilitätsprobleme zu beheben, bevor Sie ein neues Upgrade durchführen.

Nächste Schritte