Direktes Upgrade

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

In-place-Änderungen an einer Cloud SQL-Instanz vornehmen

Sie können die Edition, den Maschinentyp oder den Speichertyp Ihrer Cloud SQL-Instanz aktualisieren oder downgraden oder die Datenbankversion aktualisieren, indem Sie Änderungen direkt vornehmen. Die einfachste und am wenigsten fehleranfällige Methode zum Neukonfigurieren einer Instanz besteht darin, Änderungen direkt vorzunehmen.

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 durchführen und Nebenversion der Datenbank aktualisieren.

Mögliche speicherbezogene Änderungen im Zusammenhang mit dem Maschinentyp

Die verschiedenen Editionen unterstützen unterschiedliche Maschinentypen, die unterschiedliche Speicheroptionen verwenden. Hochleistungsfähige C4- und C4A-Maschinentypen verwenden Hyperdisk Balanced-Speicher anstelle der Persistent Disk-Optionen, die von älteren Maschinentypen verwendet werden.

Wenn Sie die verwendete Version oder den Maschinentyp ändern, kann sich auch der Speichertyp ändern. Das kann zu Ausfallzeiten und einer Änderung der Speicherkosten führen. Beim Umstieg auf Google Cloud Hyperdisk Balanced stehen zusätzliche Konfigurationsoptionen zur Verfügung. Weitere Informationen finden Sie unter Änderungen am Speicher.

Änderungen beim Speichern von PITR-Transaktionslogs

Wenn Sie eine Cloud SQL Enterprise-Instanz aktualisieren, in der die für PITR verwendeten binären Logs auf dem Laufwerk gespeichert sind, wird beim Upgrade auf Cloud SQL Enterprise Plus der Speicherort dieser Logs vom Laufwerk zu Cloud Storage verschoben. Informationen zum Ermitteln des aktuellen Speicherorts von PITR-Binärlogs 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 In-Place-Upgrades auf den Speicherort der Binärlogs auswirken können, finden Sie unter Änderungen am Speicherort von Binärlogs für die Wiederherstellung zu einem bestimmten Zeitpunkt.

Version 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 in eine andere wechseln. Cloud SQL Enterprise Plus bietet einige Vorteile und Leistungsverbesserungen, die in Cloud SQL Enterprise nicht verfügbar sind. Weitere Informationen zu den Cloud SQL-Versionen finden Sie unter Übersicht über Cloud SQL-Versionen.

Das Upgrade auf Cloud SQL Enterprise Plus dauert einige Minuten und ist nahezu ohne Ausfallzeit. Wenn Sie zur Cloud SQL Enterprise-Version zurückkehren, ist mit einer längeren Ausfallzeit zu rechnen. Bei beiden Verfahren müssen Sie die Endpunkte nicht ändern, mit denen Ihre Anwendungen verbunden sind.

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

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

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

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

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "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"
}

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

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

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "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 In-Place-Änderungen

Wenn Sie die Edition Ihrer Cloud SQL-Instanz ändern, müssen Sie möglicherweise auch die Maschinenserie ä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 Cloud SQL Enterprise auf Cloud SQL Enterprise Plus können Sie zwischen den Maschinenserien N2, C4A und C4 wählen.

Wenn Sie ein Downgrade von der Cloud SQL Enterprise Plus-Version auf die Cloud SQL Enterprise-Version durchführen, können Sie zwischen einem dedizierten Kern für allgemeine Zwecke und einer N4-Maschinenserie wählen.

Sie können den Maschinentyp auch ändern, ohne die Edition zu ändern. Nachdem Sie die Option zum Bearbeiten Ihrer Instanz ausgewählt 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 Datencache aktivieren oder deaktivieren.

Weitere allgemeine Informationen finden Sie in der Compute Engine-Dokumentation für die Maschinenserien N2, C4A, C4 und N4.

Änderungen am Speicher

Wenn Sie von einer Maschinenserie für allgemeine Zwecke oder einer N2-Maschinenserie zu einer N4-, C4A- oder C4-Maschinenserie wechseln, wird Ihr Speicher von Solid-State-Drive (SSD) zu Google Cloud Hyperdisk Balanced migriert. Für dieses Upgrade ist in der Regel nur eine minimale Ausfallzeit 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 Standard-IOPS- und ‑Durchsatzwerte sowie ‑Grenzwerte 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 des Speicherorts von Binärlogs für die Wiederherstellung zu einem bestimmten Zeitpunkt

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 den Ortswechsel gelten die folgenden Bedingungen:

• Der Vorgang dauert ungefähr die Dauer der PITR-Konfigurationseinstellung transactionLogRetentionDays, 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 speichert Cloud SQL Logs nur für den Mindestwert eines der folgenden Werte auf der Festplatte:
  • Die PITR-Konfigurationseinstellung transactionLogRetentionDays von 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.
• 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.