Direktes Upgrade

Auf dieser Seite wird beschrieben, wie Sie direkte Upgrades und Downgrades Ihrer Cloud SQL-Instanzen durchführen.

Direkte Änderungen an einer Cloud SQL-Instanz vornehmen

Mit direkten Änderungen können Sie die Edition Ihrer Cloud SQL-Instanz, ihren Maschinentyp, Speichertyp oder die Datenbankversion aktualisieren oder herabstufen. Direkte Änderungen sind die einfachste und am wenigsten fehleranfällige Methode, um eine Instanz neu zu konfigurieren.

Hinweis

Prüfen Sie, ob Ihre Instanz auf MySQL Version 8.0.31 oder höher ausgeführt wird.

Wenn Ihre Instanz eine ältere Version von MySQL verwendet, müssen Sie ein Upgrade auf MySQL 8.0.31 oder höher durchführen. Weitere Informationen finden Sie unter Direkte Datenbankaktualisierung der Hauptversion durchführen und Nebenversion der Datenbank aktualisieren.

Verschiedene Editionen unterstützen unterschiedliche Maschinentypen, die verschiedene Speicheroptionen verwenden. Die leistungsstarken Maschinentypen C4 und C4A verwenden Hyperdisk Balanced-Speicher anstelle einer der Optionen für nichtflüchtige Speicher , die von älteren Maschinentypen verwendet werden.

Wenn Sie die Edition oder den verwendeten Maschinentyp ändern, kann sich auch der Speichertyp ändern. Dies kann zu Ausfallzeiten und einer Änderung der Speicherkosten führen. Beim Wechsel zu Google Cloud Hyperdisk Balanced gibt es zusätzliche Konfigurationsoptionen, die Sie angeben können. Weitere Informationen finden Sie unter Speicheränderungen.

Änderungen am Speicherort für PITR-Transaktionslogs

Wenn Sie ein Upgrade einer Cloud SQL Enterprise-Instanz durchführen, die die für PITR verwendeten binären Logs auf dem Laufwerk speichert, wird der Speicherort dieser Logs beim Upgrade auf Cloud SQL Enterprise Plus vom Laufwerk zu Cloud Storage verschoben. Informationen zum aktuellen Speicherort von binären PITR -Logs für Ihre Instanz finden Sie unter Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden.

Eine vollständige Erklärung dazu, wie sich direkte Upgrades auf den Speicherort der binären Logs auswirken können, finden Sie unter Änderungen am Speicherort von binären Logs für PITR.

Edition einer Instanz direkt ändern

In diesem Abschnitt wird beschrieben, wie Sie die Edition Ihrer Cloud SQL-Instanz direkt in die Cloud SQL Enterprise Plus-Edition ändern oder von dieser Edition zu einer anderen wechseln. Die Cloud SQL Enterprise Plus-Edition bietet einige Vorteile und Leistungsverbesserungen, die die Cloud SQL Enterprise-Edition nicht bietet. Weitere Informationen zu Cloud SQL-Editionen finden Sie unter Übersicht über Cloud SQL-Editionen.

Das Upgrade auf die Cloud SQL Enterprise Plus-Edition dauert nur wenige Minuten und führt zu nahezu keinen Ausfallzeiten. Wenn Sie wieder zur Cloud SQL Enterprise-Edition wechseln, sind längere Ausfallzeiten zu erwarten. Bei beiden Vorgängen müssen die Endpunkte der Anwendungen, mit denen sie verbunden sind, nicht geändert werden.

Folgen Sie der Anleitung in diesem Abschnitt, um ein Upgrade einer Cloud SQL Enterprise-Instanz auf eine Cloud SQL Enterprise Plus-Version durchzuführen oder eine Cloud SQL Enterprise Plus-Instanz auf eine Cloud SQL Enterprise-Version herabzustufen.

Console

  1. Öffnen Sie in der Google Cloud Console die Cloud SQL-Instanzen Seite.

    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 Cloud SQL-Edition auswählen auf Upgrade , wenn Ihre Instanz die Cloud SQL Enterprise-Edition verwendet, oder auf Zu Enterprise wechseln , wenn Ihre Instanz die Cloud SQL Enterprise Plus-Edition verwendet.
  5. Geben Sie im daraufhin geöffneten Steuerfeld die Konfiguration Ihrer Instanz mit der neuen Edition an. Weitere Informationen finden Sie unter Optionen beim Vornehmen direkter Änderungen.
  6. Geben Sie Ihre Instanz-ID ein, um diese Auswahl zu bestätigen, und klicken Sie dann je nach Upgrade oder Downgrade auf Edition aktualisieren oder Edition wechseln.

Sie können eine Änderung der Edition auch auf der Seite Instanzen starten, indem Sie in der Spalte Aktionen der Instanz Bearbeiten auswählen.

Wenn Ihre Instanz die Cloud SQL Enterprise-Edition verwendet, können Sie außerdem ein Upgrade starten, indem Sie auf der Instanzseite im Abschnitt Konfiguration neben dem Feld „Edition“ auf den Link Upgrade klicken.

gcloud

Im folgenden Codebeispiel für [`gcloud sql instance patch`](/sdk/gcloud/reference/sql/instances/patch) wird gezeigt, wie Sie ein Upgrade Ihrer Instanz auf Cloud SQL Enterprise Plus ausführen:

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

Ersetzen Sie Folgendes:

  • PROJECT_ID: Die Projekt-ID der Instanz, die Sie aktualisieren möchten.
  • INSTANCE_ID: Der Name der Instanz, die Sie aktualisieren möchten.
  • MACHINE_TYPE: Der Maschinentyp der Instanz, auf die Sie ein Upgrade ausführen möchten. Weitere Informationen zu Maschinentypen für Cloud SQL Enterprise Plus finden Sie unter Maschinentypen für Cloud SQL Enterprise Plus-Instanzen.

REST

Mit dem folgenden Befehl wird Ihre Instanz auf die Cloud SQL Enterprise Plus-Edition aktualisiert und ein Neustartvorgang ausgelöst.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Die Projekt-ID der Instanz, die Sie aktualisieren möchten.
  • INSTANCE_ID: Die Instanz-ID der Instanz, die Sie aktualisieren möchten.
  • MACHINE_TYPE: Der Maschinentyp der Instanz, auf die Sie ein Upgrade ausführen möchten. Weitere Informationen zu Maschinentypen für Cloud SQL Enterprise Plus finden Sie unter Maschinentypen für Cloud SQL Enterprise Plus-Instanzen.

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

JSON-Text der Anfrage: 

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Mit dem folgenden Befehl wird Ihre Instanz auf die Cloud SQL Enterprise Plus-Edition aktualisiert und ein Neustartvorgang ausgelöst.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Die Projekt-ID der Instanz, die Sie aktualisieren möchten.
  • INSTANCE_ID: Die Instanz-ID der Instanz, die Sie aktualisieren möchten.
  • MACHINE_TYPE: Der Maschinentyp der Instanz, auf die Sie ein Upgrade ausführen möchten. Weitere Informationen zu Maschinentypen für Cloud SQL Enterprise Plus finden Sie unter Maschinentypen für Cloud SQL Enterprise Plus-Instanzen.

HTTP-Methode und URL: 

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

JSON-Text der Anfrage: 

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Optionen für direkte Änderungen

Wenn Sie die Edition Ihrer Cloud SQL-Instanz ändern, müssen Sie möglicherweise auch die Maschinenreihe ändern, was sich wiederum auf den Speichertyp auswirkt.

Änderungen an der Maschine

Wenn Sie die Edition ändern, müssen Sie auch den Maschinentyp ändern. Weitere Informationen zu den von Cloud SQL unterstützten Maschinenreihen finden Sie unter Maschinenreihe auswählen.

Beim Upgrade von der Cloud SQL Enterprise-Edition auf die Cloud SQL Enterprise Plus-Edition können Sie zwischen den N2, C4A und C4 Maschinenreihen wählen.

Beim Downgrade von der Cloud SQL Enterprise Plus-Edition auf die Cloud SQL Enterprise-Edition können Sie zwischen einer allgemeinen Maschine mit dedizierten Kernen, und einer Maschine der N4-Reihe wählen.

Sie können den Maschinentyp auch ändern, ohne die Edition zu ändern. Nachdem Sie die Instanz bearbeitet haben, rufen Sie im Bereich Instanz anpassen den Unterabschnitt Maschine von Maschinenkonfiguration auf. Über das Drop-down-Menü können Sie einen anderen Maschinentyp auswählen. Sie können auch eine andere Anzahl von vCPUs auswählen und den Daten-Cache aktivieren oder deaktivieren.

Weitere allgemeine Informationen finden Sie in der Compute Engine-Dokumentation zu den N2, C4A, C4 und N4 Maschinenreihen.

Speicheränderungen

Wenn Sie von einer allgemeinen oder einer Maschine der N2-Reihe zu einer Maschine der N4, C4A- oder C4-Reihe wechseln, wird Ihr Speicher von einem Solid-State-Laufwerk (SSD) zu Google Cloud Hyperdisk Balanced Speicher migriert. Für dieses Upgrade sind in der Regel nur minimale Ausfallzeiten erforderlich.

Google Cloud Hyperdisk Balanced-Speicher kann für Ihren Anwendungsfall angepasst werden, indem Sie Folgendes festlegen:

  • Speicherkapazität
  • Bereitgestellte IOPS
  • Bereitgestellter Durchsatz

Google Cloud Hyperdisk Balanced legt Standardwerte und Limits für IOPS und Durchsatz basierend auf der Konfiguration Ihrer Instanz fest, einschließlich des Maschinentyps und der Speicherkapazität. Die Speicherkapazität begrenzt den Standardwert und der Maschinentyp legt den Höchstwert für IOPS und Durchsatz fest. Weitere Informationen finden Sie unter Speicheroption auswählen.

Änderungen am Speicherort von binären Logs für PITR

Wenn Ihre Cloud SQL Enterprise-Instanz Transaktionslogs für PITR auf dem Laufwerk speichert, wird beim Starten des Upgrades auf Cloud SQL Enterprise Plus der Speicherort dieser Logs auf Cloud Storage umgestellt.

Für die Änderung des Speicherorts gelten die folgenden Bedingungen:

  • Der Vorgang dauert ungefähr die Dauer der transactionLogRetentionDays PITR-Konfigurationseinstellung, um die Umstellung auf Cloud Storage abzuschließen.
  • Wenn Sie Werte für das Flag expire_logs_days oder binlog_expire_logs_seconds für Ihre Instanz festgelegt haben, bleiben diese Werte erhalten.
  • Während der Umstellung auf Cloud Storage können Sie die Werte für die Flags expire_logs_days oder binlog_expire_logs_seconds auf Ihrer Instanz nicht ändern.
  • Während der Umstellung auf Cloud Storage sollten Sie die PITR-Konfigurationseinstellung transactionLogRetentionDays nicht ändern. Selbst wenn Sie transactionLogRetentionDays erhöhen, werden binäre Logs nicht länger als den Standardwert von 7 Tagen auf einer Cloud SQL Enterprise-Instanz aufbewahrt.
  • Während der Umstellung werden in Cloud SQL nur Logs auf dem Laufwerk für den Mindestwert eines der folgenden Werte gespeichert:
    • Die PITR-Konfigurationseinstellung transactionLogRetentionDays von vor der Umstellung, die standardmäßig 7 Tage beträgt.
    • Die Flags expire_logs_days oder binlog_expire_logs_seconds, die für Ihre Instanz manuell festgelegt wurden.
  • Nach der Umstellung behält Cloud SQL die gleiche Anzahl an binären Logs auf dem Laufwerk bei, die Sie vor dem Wechsel hatten. Es sei denn, Sie haben die expire_logs_days oder binlog_expire_logs_seconds Flags in Ihrer Instanz festgelegt. Wenn Sie diese Flags festgelegt haben, speichert Cloud SQL binäre Logs auf dem Laufwerk basierend auf dem Mindestwert der Konfigurationseinstellung transactionLogRetentionDays oder dem Wert der Flags.

Standardeinstellungen für Sicherung und Logspeicher von Cloud SQL Enterprise Plus

Nachdem der Wechsel zu Cloud Storage für eine Instanz abgeschlossen ist, speichert Cloud SQL weiterhin Kopien binärer Logs zu Replikationszwecken auf dem Laufwerk. Das Speichern binärer Logs auf einem Laufwerk kann nützlich sein, wenn Sie binäre Logs mit dem Dienstprogramm mysqlbinlog durchsuchen möchten.

Wenn Sie die Flags expire_logs_days und binlog_expire_logs_seconds vor dem Upgrade auf Ihrer Instanz konfiguriert haben, bleiben die konfigurierten Werte erhalten.

Da die binären Logs, die zum Ausführen von PITR verwendet werden, nach der Umstellung jetzt in Cloud Storage gespeichert werden, müssen die Werte der Flags die Aufbewahrung von Transaktionslogs auf dem erwarteten Laufwerk widerspiegeln. Cloud SQL speichert Logs auf dem Laufwerk nur für einen der folgenden Mindestwert:

  • die PITR-Konfigurationseinstellung transactionLogRetentionDays vor der Umstellung, standardmäßig 7 Tage
  • die Flags expire_logs_days oder binlog_expire_logs_seconds, die für Ihre Instanz manuell festgelegt wurden

Wenn Sie Speicherplatz sparen möchten, konfigurieren Sie nach Abschluss des Upgrades den Wert des Flags expire_logs_days oder binlog_expire_logs_seconds auf den Wert von 1 Tag, damit Sie die zugewiesene Laufwerkgröße und Laufwerksspeicherkosten reduzieren können. Weitere Informationen zum Speichern von Transaktionslogs und PITR finden Sie unter Logspeicher für PITR.

Nach Abschluss des Upgrades auf Cloud SQL Enterprise Plus wird die standardmäßige Aufbewahrungsdauer für Transaktionslogs für alle aktualisierten Instanzen auf 14 Tage erhöht. Für diese Erhöhung und jede andere Erhöhung, die Sie für die Aufbewahrungsdauer des Transaktionslogs konfigurieren, muss der neue und erhöhte Wert erreicht werden, um das vollständige Aufbewahrungsdauer von PITR zu erreichen. Beispiel: Wenn der alte Wert für die Aufbewahrung von Transaktionslogs 7 Tage beträgt und der neue Wert auf 14 erhöht wird, beträgt das Zeitfenster für PITR in den ersten 7 Tagen nach dem Upgrade nur 7 Tage. Am 8. Tag beträgt das Zeitfenster für PITR 8 Tage, am 9. Tag werden es dann 9 Tage, bis das Aufbewahrungsfenster schließlich auf 14 Tage am 14. Tag erhöht wird.

Darüber hinaus wird die Standardanzahl automatischer Sicherungen von 8 auf 15 erhöht.

Wenn Sie nach einem Upgrade der Hauptversion ein Upgrade auf Cloud SQL Enterprise Plus ausführen, können Sie PITR nicht für einen Zeitpunkt ausführen, der vor dem Upgrade der Hauptversion liegt. Diese Beschränkung gilt auch dann, wenn die Aufbewahrungsdauer diesen Zeitraum abdeckt. Sie können Ihre Instanz auf einen bestimmten Zeitpunkt nach dem Start des Upgrades der Hauptversion wiederherstellen.