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.

Upgrade einer Hauptversion planen

1. Prüfen Sie, ob Sie die erforderliche Rolle für ein Hauptversionsupgrade haben: Cloud SQL-Inhaber oder Cloud SQL-Administrator.

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

   gcloud

   Informationen zur Installation und zu den ersten Schritten mit der gcloud CLI finden Sie unter gcloud CLI installieren. Informationen zum Starten von Cloud Shell finden Sie unter Cloud Shell verwenden.

   So prüfen Sie, auf welche Datenbankversionen Sie ein In-Place-Upgrade auf Ihrer Instanz ausführen können:

   1. Führen Sie den folgenden Befehl aus:

   gcloud sql instances describe INSTANCE_NAME
      

   Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz.

   2. Suchen Sie in der Ausgabe des Befehls nach dem Abschnitt mit der Bezeichnung upgradableDatabaseVersions.
   3. Jeder Abschnitt gibt eine Datenbankversion zurück, die für ein Upgrade verfügbar ist. Prüfen Sie in jedem Unterabschnitt die folgenden Felder.
   • majorVersion: die Hauptversion, auf die das In-Place-Upgrade ausgerichtet werden kann.
   • name: den String der Datenbankversion, der die Hauptversion enthält. Bei Cloud SQL for MySQL enthält dieses Feld auch die Nebenversion der Datenbank.
   • displayName: den Anzeigenamen der Datenbankversion.

   REST Version 1

   Mit der Methode instances.get der Cloud SQL Admin API können Sie prüfen, welche Zieldatenbankversionen für ein direktes Upgrade auf eine neue Hauptversion verfügbar sind.

   Ersetzen Sie diese Werte in den folgenden Anfragedaten:

   • INSTANCE_NAME: ist der Name der Instanz.

   HTTP-Methode und URL:

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

   Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

   curl (Linux, macOS oder Cloud Shell)

   Führen Sie folgenden Befehl aus:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell (Windows)

   Führen Sie folgenden Befehl aus:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   Sie sollten in etwa folgende JSON-Antwort erhalten:

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   REST v1beta4

   Mit der Methode instances.get der Cloud SQL Admin API können Sie prüfen, welche Zieldatenbankversionen für ein direktes Upgrade einer Instanz auf eine Hauptversion verfügbar sind.

   Ersetzen Sie diese Werte in den folgenden Anfragedaten:

   • INSTANCE_NAME: ist der Name der Instanz.

   HTTP-Methode und URL:

   GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

   Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

   curl (Linux, macOS oder Cloud Shell)

   Führen Sie folgenden Befehl aus:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell (Windows)

   Führen Sie folgenden Befehl aus:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   Sie sollten in etwa folgende JSON-Antwort erhalten:

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   Eine vollständige Liste der von Cloud SQL unterstützten Datenbankversionen finden Sie unter Datenbankversionen und Versionsrichtlinien.

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

   • MySQL 9.7
   • MySQL 8.4
   • MySQL 8.0
   • MySQL 5.7

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

4. Führen Sie die Vorabprüfung für Upgrades aus.

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

6. 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. Wenn Sie ein Upgrade von MySQL 8.0 auf MySQL 8.4 durchführen, verwenden alle neuen Nutzer, die Sie nach dem Upgrade erstellen, das Authentifizierungs-Plug-in caching_sha2_password anstelle des verworfenen Plug-ins mysql_native_password. Sie können auch vorhandene Nutzerkonten aktualisieren, um das Authentifizierungs-Plug-in caching_sha2_password zu verwenden. Verwenden Sie den folgenden Befehl, um Ihre vorhandenen Datenbanknutzerkonten so zu ändern, dass das Authentifizierungs-Plug-in caching_sha2_password verwendet wird:

   ALTER USER 'username'@'%'
   IDENTIFIED WITH caching_sha2_password BY 'user_password';
        

   Ersetzen Sie username und user_password durch die Werte für das Datenbanknutzerkonto mit integrierter Authentifizierung, das Sie aktualisieren.

2. Prüfen Sie den Speicherplatz und den Maschinentyp der Instanz.

   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.

Erforderliche Konfiguration für die Verwendung von MySQL 8.4 oder höher mit dem Cloud SQL Auth-Proxy

Wenn Sie MySQL 8.4 oder höher mit dem Cloud SQL Auth-Proxy verwenden, müssen Sie die Datenbankkonfiguration Ihrer Anwendung mit der MySQL-Konfigurationseinstellung allowPublicKeyRetrieval=true konfigurieren. Sie müssen Ihre Clientanwendungen mit dieser Konfiguration aktualisieren, bevor Sie die Datenbankversion aktualisieren.

Wenn Sie beispielsweise den mysql-Client verwenden, verwenden Sie das Flag --get-server-public-key:

mysql -u username -p --get-server-public-key

Wenn Sie die Programmiersprache Java verwenden, verwenden Sie Folgendes:

config.setJdbcUrl("jdbc:mysql://" + dbHost + ":" + dbPort + "/" + dbName);
config.addDataSourceProperty("allowPublicKeyRetrieval", "true");

Upgradebereitschaft für Ihre Instanz prüfen

Mit Cloud SQL können Sie vor einem Upgrade der Hauptversion eine Vorabprüfung Ihrer Instanz ausführen. Diese Vorabprüfung ist ein Vorgang mit langer Ausführungszeit (LRO), bei dem geprüft wird, ob Ihre Instanz für ein Upgrade bereit ist. So können Sie potenzielle Probleme wie Inkompatibilitäten, Konfigurationsprobleme oder Datenprobleme vor dem Upgrade erkennen.

Cloud SQL kann die Vorabprüfung parallel zu Ihrer Arbeitslast ausführen. Wenn Sie die Vorabprüfung vor dem Upgrade einer Hauptversion ausführen, können Sie einen Upgradefehler verhindern.

Wenn Sie die Vorabprüfung ausführen, geschieht Folgendes:

• Keine Probleme gefunden: Die Vorabprüfung wurde erfolgreich abgeschlossen und es wurden keine Probleme gefunden.
• Probleme gefunden: Die Vorabprüfung wurde erfolgreich abgeschlossen, es wurden jedoch Fehler gefunden, die das Upgrade blockieren. Die Probleme müssen vor dem Upgrade behoben werden.
• Warnungen gefunden: Die Vorabprüfung wurde erfolgreich abgeschlossen und es wurden Warnungen gefunden. Prüfen Sie die Warnungen. Wir empfehlen, alle Probleme zu beheben, bevor Sie mit dem Upgrade fortfahren.

Je nach den Ergebnissen der Vorabprüfung können Sie entweder mit dem Upgrade fortfahren oder die erkannten Probleme vor dem Upgrade beheben.

Beschränkungen

Beachten Sie bei der Vorabprüfung des Upgrades auf eine Hauptversion die folgenden Einschränkungen:

• Der Instanzstatus muss auf RUNNING gesetzt sein.

• Für die Instanz dürfen keine blockierenden Vorgänge ausstehen. Wenn ein blockierender Vorgang aussteht, führt die Vorabprüfung zu einem Fehler mit der folgenden Meldung:

  Operation failed because another operation was already in progress. Try
  your request after the current operation is complete.
  

• Für die Vorabprüfung muss eine Verbindung zu allen Datenbanken in der Instanz hergestellt werden. Wenn eine Datenbank nicht zugänglich, gesperrt oder nicht reagiert, kann die Vorabprüfung fehlschlagen oder Fehler anzeigen. Wir empfehlen, die Vorabprüfung auszuführen, wenn die Datenbanklast niedrig ist.

• Bei der Vorabprüfung wird die Kompatibilität des Upgrades zwischen aufeinanderfolgenden Hauptversionen von Cloud SQL for MySQL geprüft. Sie können beispielsweise die Vorabprüfung für das Upgrade von MySQL 5.7 auf MySQL 8.0, das Upgrade von MySQL 8.0 auf MySQL 8.4 und dann das Upgrade von MySQL 8.4 auf MySQL 9.7 ausführen.

  Die Vorabprüfung unterstützt nicht die Prüfung eines Upgrades einer Nebenversion innerhalb derselben Hauptversion. Sie können beispielsweise keine Vorabprüfung für ein Upgrade von MySQL 8.0.31 auf 8.0.45 durchführen.

• Die Vorabprüfung ist auf drei Stunden begrenzt. Wenn die Vorabprüfung das Limit von drei Stunden überschreitet, kommt es zu einer Zeitüberschreitung und der Vorgang wird automatisch abgebrochen.

• Das Upgrade Checker-Dienstprogramm von MySQL Shell erkennt möglicherweise nicht alle Inkompatibilitäten während der Vorprüfung. Es ist immer noch möglich, dass das Upgrade fehlschlägt. Es ist auch möglich, dass einige nicht behobene Warnungen ein Upgrade auf eine Hauptversion blockieren.

Hinweis

• Achten Sie darauf, dass die Cloud SQL Admin API für Ihre Instanz aktiviert ist.
• Prüfen Sie, ob Sie die IAM-Berechtigung cloudsql.instances.preCheckMajorVersionUpgrade haben.

Vorabprüfung durchführen

So führen Sie die Vorabprüfung für das Upgrade auf eine Hauptversion durch:

Ergebnisse der Vorabprüfung ansehen

Nach Abschluss der Vorabprüfung ist Ihre Instanz entweder bereit für das Upgrade oder es gibt Probleme, die Ihre Aufmerksamkeit erfordern.

Bereit für Upgrade

Wenn die Vorabprüfung erfolgreich abgeschlossen wurde und das Array preCheckResponse leer ist, wurden keine Probleme oder Warnungen gefunden. Ihre Instanz ist für das Upgrade der Hauptversion bereit. Weitere Informationen finden Sie unter Upgrade der Hauptversion durchführen.

Nicht bereit für Upgrade

Wenn die Vorabprüfung erfolgreich ausgeführt wurde und das Array preCheckResponse Probleme enthält, ist Ihre Instanz nicht für das Upgrade bereit und muss überprüft werden. Die erkannten Probleme können das Upgrade blockieren oder auch nicht. Diese Probleme werden in der preCheckResponse mit den folgenden Nachrichtentypen vermerkt:

Jeder Problemtyp enthält ein message- und ein actions_required-Feld. Prüfen Sie jedes Problem, um den Typ zu verstehen und zu erfahren, wie Sie es beheben können. Weitere Informationen zu häufigen Problemen und deren Lösungen finden Sie unter Häufige Fehler bei der Vorabprüfung des Hauptversionsupgrades.

Führen Sie nach dem Beheben der Probleme die Vorabprüfung noch einmal aus, um zu bestätigen, dass Ihre Instanz für das Upgrade bereit ist. Fahren Sie dann mit dem Upgrade der Instanz fort, sobald die Vorabprüfung abgeschlossen ist.

Vorabprüfung für ein Upgrade einer Hauptversion abbrechen

Sie können einen Vorabprüfungsvorgang für ein Upgrade der Hauptversion für Cloud SQL for MySQL abbrechen.

Hinweis

Wenn Sie die Vorabprüfung des Upgrades der Hauptversion abbrechen möchten, benötigen Sie die ID des Vorabprüfungsvorgangs. Sie müssen diese ID im gcloud- oder REST API-Befehl angeben, damit Cloud SQL weiß, welcher Vorgang abgebrochen werden soll.

Die Vorgangs-ID wird im Feld name der Antwort zurückgegeben.

Sie können die Vorgangs-ID auch durch einen operations.list-Aufruf auf der Cloud SQL-Instanz ermitteln.

Kündigung durchführen

Sie können die gcloud- oder REST API-Befehle verwenden, um eine Vorabprüfung abzubrechen.

Abgebrochenen Status prüfen

Mit den gcloud- oder REST API-Befehlen können Sie den Status eines abgebrochenen Vorabprüfvorgangs prüfen.

Fehlerbehebung bei Kündigung

Upgrade der Hauptversion durchführen

Sie können die Hauptversion einer einzelnen Cloud SQL-Instanz oder die Hauptversion einer primären Instanz aktualisieren und alle zugehörigen Replikate in das Upgrade einbeziehen, einschließlich kaskadierender Replikate und regionenübergreifender Replikate.

Upgrade der Hauptversion einer einzelnen Instanz durchführen

Wenn Sie einen Upgradevorgang für eine einzelne Instanz starten, führt Cloud SQL Folgendes aus:

1. Prüft die Konfiguration Ihrer Instanz, um sicherzustellen, dass die Instanz für ein Upgrade kompatibel ist.
2. Nachdem Cloud SQL die Konfiguration überprüft hat, wird die Instanz deaktiviert.
3. Erstellt eine Sicherung vor dem Upgrade.
4. Führt das Upgrade auf der Instanz aus.
5. Stellt Ihre Instanz zur Verfügung.
6. Erstellt eine Sicherung nach dem Upgrade.

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
}

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.

Replikate in das Upgrade der Hauptversion einbeziehen

Wenn Ihre primäre Instanz Replikate hat, können Sie alle Replikate in das Upgrade einbeziehen. Cloud SQL kann alle Replikate der primären Instanz aktualisieren, einschließlich regionenübergreifender Replikate und kaskadierender Replikate.

Wenn Sie Replikate in ein Upgrade der Hauptversion einbeziehen, führt Cloud SQL Folgendes aus:

1. Prüft die Konfiguration Ihrer primären Instanz und Replikate, um sicherzustellen, dass die Instanz und die Replikate für ein Upgrade kompatibel sind.
2. Macht die primäre Instanz nicht verfügbar.
3. Erstellt eine Sicherung der primären Instanz vor dem Upgrade.
4. Die Replikation wird für alle Replikate beendet.
5. Führt das Upgrade auf der primären Instanz aus.
6. Wenn das Upgrade auf der primären Instanz erfolgreich ist, ist die primäre Instanz wieder verfügbar und die Replikation wird neu gestartet.
7. Cloud SQL erstellt eine Sicherung der primären Instanz nach dem Upgrade.
8. Cloud SQL aktualisiert alle Replikate.

Auch wenn das Upgrade der Hauptversion eines Replikats fehlschlägt, ist die primäre Instanz weiterhin verfügbar.

Wenn Sie Replikate in ein Upgrade der Hauptversion einbeziehen möchten, können Sie nicht dieCloud de Confiance Console oder Terraform verwenden. Sie können nur die gcloud CLI oder die Cloud SQL Admin API verwenden.

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 schnell 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. Wenn Sie ein Upgrade von MySQL 8.0 auf MySQL 8.4 ausführen, ist die Sicherung vor dem Upgrade mit Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. und die Sicherung nach dem Upgrade mit Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0. gekennzeichnet. Wenn Sie ein Upgrade von MySQL 8.4 auf MySQL 9.7 ausführen, ist die Sicherung vor dem Upgrade mit Pre-upgrade backup, MYSQL_8_4 to MYSQL_9_7. und die Sicherung nach dem Upgrade mit Post-upgrade backup, MYSQL_9_7 from MYSQL_8_4. 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

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.

   In MySQL 8.0 gibt es neue Änderungen an den Sicherheits- und Kontoverwaltungssystemen. Weitere Informationen finden Sie unter Das ist neu in MySQL 8.0.

   Cloud SQL for MySQL hat diese Änderungen übernommen und die mit der Rolle cloudsqlsuperuser verknüpften Nutzerberechtigungen erweitert. Nutzer, die in der MySQL-Version 5.7 der Instanz erstellt wurden, haben möglicherweise nicht die gleichen Berechtigungen wie Nutzer, die direkt in MySQL 8.0 erstellt wurden. Nutzer, die ein Upgrade von MySQL 5.7 auf MySQL 8.0 ausführen, haben beispielsweise nicht die Berechtigung CONNECTION_ADMIN. Daher können sie den Befehl KILL nicht für Sitzungen anderer Nutzer ausführen. Informationen zum Aktualisieren von Nutzerberechtigungen finden Sie im Verfahren in diesem Abschnitt.

   Wenn Sie ein Upgrade von MySQL 8.0 auf MySQL 8.4 durchführen, gibt es zusätzliche Änderungen an den Nutzerberechtigungen. Dazu gehören das Hinzufügen von Berechtigungen, die in MySQL 8.4 eingeführt wurden, und das Entfernen von Berechtigungen, die in MySQL 8.0 vorhanden waren. Weitere Informationen finden Sie unter MySQL 8.4-Nutzerberechtigungen (cloudsqlsuperuser).

   So aktualisieren Sie Nutzerberechtigungen in MySQL 8.0, MySQL 8.4 oder MySQL 9.7:

   1. Erstellen Sie einen Nutzer mit der standardmäßig zugewiesenen Rolle cloudsqlsuperuser.

   2. Verwenden Sie diesen Nutzer, um eine Verbindung zur Instanz herzustellen, damit Sie die Berechtigungen anderer Nutzer aktualisieren können.

      Führen Sie beispielsweise den folgenden Befehl aus, um die Berechtigungen der Nutzer zu prüfen:

      SHOW GRANTS for 'admin'@'%',

      Führen Sie den folgenden Befehl aus, um einem Nutzer Berechtigungen zu gewähren, z. B. die Berechtigung, den Befehl KILL zum Beenden von Verbindungen zu verwenden:

      GRANT CONNECTION_ADMIN ON *.* to 'admin'@'%';

      Führen Sie den folgenden Befehl aus, um dem Nutzer admin'@'% die Rolle cloudsqlsuperuser zuzuweisen:

      GRANT 'cloudsqlsuperuser' to 'admin'@'%';

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.

4. Optional: Wenn Sie ein Upgrade auf Cloud SQL for MySQL 8.4 oder MySQL 9.7 durchgeführt haben, aktualisieren Sie auch alle Connectors, Clients und MySQL-Shells auf MySQL 8.4 oder MySQL 9.7.

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.

Fehler-Logs 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.

Verwenden Sie die Cloud de Confiance by S3NSConsole, um Fehlerlogs aufzurufen:

1. Rufen Sie in der Cloud de Confiance Console die Seite Cloud SQL-Instanzen auf.

   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"

   Sie können entweder alle Logs prüfen, die innerhalb eines bestimmten Zeitraums gemeldet wurden, oder Logs nach Schweregrad filtern. Eine gängige Option zur Fehlerbehebung ist die Auswahl der folgenden Filter:

   • Notfall
   • Benachrichtigung
   • Kritisch
   • Fehler

   Bei der Vorabprüfung und beim Upgrade von MySQL-Version 5.7 auf MySQL 8.0 können einige bekannte Probleme auftreten. Hilfe zur Fehlerbehebung bei diesen Problemen finden Sie unter Fehlerbehebung beim direkten Upgrade der Hauptversion auf MySQL 8.0.

MVU-Vorgang mit langer Ausführungszeit

Mit einem Upgrade der Hauptversion sind zwei zugrunde liegende Aufgaben verbunden:

• Vorabprüfung: Gibt einen Zeitüberschreitungsfehler zurück, wenn der Vorgang nicht innerhalb von drei Stunden abgeschlossen ist.
• Upgradevorgang: Gibt einen Zeitüberschreitungsfehler zurück, wenn er nicht innerhalb von sechs Stunden abgeschlossen wird.

Wenn die Instanz einen laufenden MAJOR_VERSION_UPGRADE-Vorgang hat, der länger als erwartet dauert, prüfen Sie die MySQL-Fehlerlogs. Dies kann folgende Ursachen haben:

• Eine große Anzahl von Tabellen, Ansichten oder Indexen
• Unzureichende Ressourcen wie CPU oder Arbeitsspeicher
• Wichtige Transaktionen, die das Herunterfahren von Datenbanken blockieren, damit der Upgradeprozess beginnen kann. Sie können die Cloud de Confiance Console verwenden, um aktuelle Prozesse zu prüfen.

Häufige Fehler bei der Vorabprüfung von Upgrades auf Hauptversionen

Häufige Probleme bei Upgrades von MySQL 5.7 auf MySQL 8.0:

• Hinzufügen neuer reservierter Keywords, z. B. RANKS, GROUPS, FUNCTION, in gespeicherten Prozeduren, Triggern und anderen Datenbankobjekten. Weitere Informationen finden Sie unter Schlüsselwörter und reservierte Wörter.
• Ungültige UTF-Zeichen in Tabellendefinitionen.
• 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.
• Fremdschlüsseleinschränkung in Namen mit mehr als 64 Zeichen.
• Räumlicher Datentyp in einem gemischten Index von Spalten. Weitere Informationen finden Sie unter Räumliche Datentypen.

Hilfe zur Fehlerbehebung bei Fehlern und bekannten Problemen während der Vorabprüfung von MySQL 5.7 auf MySQL 8.0 finden Sie unter Fehlerbehebung beim direkten Upgrade der Hauptversion auf MySQL 8.0. Weitere Informationen zu häufigen MySQL-Problemen finden Sie unter Installation auf das Upgrade vorbereiten und Upgrade auf MySQL 8.0 ausführen.

Häufige Probleme bei Upgrades von MySQL 8.0 auf MySQL 8.4:

• Veraltete Replikationsterminologie. Die Begriffe MASTER und SLAVE werden vollständig aus MySQL 8.4 entfernt.

  Wenn Sie noch Befehle oder Konfigurationen mit diesen Begriffen verwenden, müssen Sie sie ersetzen oder entfernen. Weitere Informationen zum Entfernen und Ersetzen dieser Begriffe finden Sie unter Was ist neu in MySQL 8.4 seit MySQL 8.0.

Häufige Probleme bei Upgrades von MySQL 8.4 auf MySQL 9.7:

• Wenn Sie cloudsql_vector für Ihre Instanz aktiviert haben, können Sie vor dem Upgrade keinen sekundären Nicht-Vektorindex für eine Spalte mit Cloud SQL-Vektoreinbettungen haben. Möglicherweise wird die folgende Fehlermeldung angezeigt:

  Non-vector secondary indexes are disallowed on vector columns when cloudsql_vector is enabled.

  Löschen Sie den sekundären Index, bevor Sie ein Upgrade auf MySQL 9.7 durchführen, um dieses Problem zu beheben.

• Sie haben vorhandene Vektoreinbettungen in Ihrer Cloud SQL 8.4-Datenbank, aber cloudsql_vector auf off gesetzt. Im Rahmen des Upgrades auf MySQL 9.7 werden alle Vektordaten in das MySQL-Community-Format migriert, anstatt in das VARBINARY-Format, das von Cloud SQL for MySQL 8.4 und früheren Datenbanken verwendet wird. Damit die Vektordaten korrekt migriert werden, können Sie das Flag cloudsql_vector auf on aktualisieren und mit dem Upgrade auf MySQL 9.7 fortfahren. Beim Upgrade werden Ihre Vektordaten in das Community-basierte Format migriert. Alternativ können Sie das Flag cloudsql_vector auf off setzen und die Vektordaten vor dem Upgrade manuell in Ihrer MySQL 8.4-Datenbank löschen.
• Sie haben noch integrierte Datenbanknutzerkonten, die das Plug-in mysql_native_password verwenden. Das Plug-in wird vollständig aus Cloud SQL for MySQL 9.7 entfernt. Wenn Nutzerkonten das mysql_native_password-Plug-in verwenden, können diese Konten keine Verbindung zu Ihrer Datenbank herstellen. Sie müssen alle verbleibenden Konten so ändern, dass das Plug-in caching_sha2_password verwendet wird, bevor Sie ein Upgrade auf Cloud SQL for MySQL 9.7 durchführen.

Primäre Instanz auf der vorherigen Hauptversion wiederherstellen

Wenn das aktualisierte Datenbanksystem nicht wie erwartet funktioniert, müssen Sie die primäre 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.

So stellen Sie eine primäre Instanz auf die vorherige Version wieder her:

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 verwenden, fügen Sie die Lesereplikate 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 sind die Einschränkungen für ein In-Place-Upgrade der Hauptversion aufgeführt.

• Ein direktes Upgrade einer Hauptversion ist bei einem externen Replikat nicht möglich.
• Das Upgrade von Instanzen von MySQL 5.7 auf MySQL 8.0 mit mehr als 512.000 Tabellen kann lange dauern und eine Zeitüberschreitung verursachen.
• Das Upgrade von Instanzen von MySQL 8.0 auf MySQL 8.4 mit mehr als 512.000 Tabellen kann lange dauern und eine Zeitüberschreitung verursachen.

• Wenn Sie ein Upgrade von MySQL 8.0 auf MySQL 8.4 durchführen und ein Replikat auf MySQL 8.4 aktualisiert haben, die primäre Instanz jedoch nicht, können Sie auf einer nicht aktualisierten primären Instanz ein neues Nutzerkonto mit dem verworfenen Authentifizierungs-Plug-in mysql_native_password erstellen. Um diese Situation zu vermeiden, sollten Sie die primäre Instanz unmittelbar nach dem Upgrade der Replikate aktualisieren oder neue Nutzerkonten nur auf der primären Instanz mit dem folgenden Befehl erstellen.

  CREATE USER 'USERNAME'@'%' IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

  Ersetzen Sie USERNAME und PASSWORD durch die entsprechenden Werte.

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 Anzahl von vCPUs oder Arbeitsspeicher hat, kann das Upgrade länger dauern.

Wenn Ihre Instanz zu viele Datenbanken oder Tabellen hostet oder Ihre Datenbanken sehr groß sind, kann das Upgrade Stunden dauern oder sogar eine Zeitüberschreitung erfolgen, da die Gesamtupgradedauer der Anzahl der Objekte in Ihren Datenbanken entspricht. Wenn Sie mehrere Instanzen aktualisieren müssen, wird die Upgradedauer proportional erhöht. Wenn Sie Replikate in das Upgrade einbeziehen, kann der Upgradevorgang je nach Anzahl der Replikate, die Ihre primäre Instanz hat, bis zu einer Stunde dauern.

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 eines Replikats unterbrochen wird?

Wenn die Replikation nach dem Upgrade eines Replikats unterbrochen wird, setzt Cloud SQL das Replikat auf die MySQL-Hauptversion der primären Instanz zurück. Sie können das Replikat noch einmal aktualisieren. Wenn das Problem jedoch weiterhin besteht, kann die Replikation wieder fehlschlagen. Aus diesem Grund empfehlen wir, Ihre Replikate einzubeziehen, wenn Sie ein Upgrade der Hauptversion durchführen, anstatt jedes Replikat separat zu aktualisieren.

Wenn das Replikat nicht auf dieselbe Hauptversion wie Ihre primäre Instanz zurückgesetzt 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 der primären Instanz 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

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

Warum wurde mein aktualisiertes Replikat auf die vorherige Hauptversion zurückgesetzt?

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 Keywords 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

• Informationen über die Verbindungsoptionen einer Instanz
• Weitere Informationen über das Importieren und Exportieren von Daten
• Datenbank-Flags festlegen