Diese Seite wurde von der Cloud Translation API übersetzt.

Erweiterte Notfallwiederherstellung (Disaster Recovery, DR) verwenden

Auf dieser Seite wird die Verwendung der erweiterten Notfallwiederherstellung (Disaster Recovery, DR) beschrieben. Die erweiterte Notfallwiederherstellung bietet zwei Hauptfunktionen:

Mit dem Replikat-Failover können Sie bei einem regionalen Ausfall ein Failover von Ihrer primären Instanz auf das DR-Replikat ausführen.
Mit Switchover können Sie die Rollen der primären Instanz und eines DR-Replikats ohne Datenverlust umkehren. Mit Switchover können Sie eine Bereitstellung nach dem Replikat-Failover in ihren ursprünglichen Bereitstellungsstatus wiederherstellen oder die Notfallwiederherstellung mit Switchover testen.

Die erweiterte Notfallwiederherstellung wird nur auf Cloud SQL Enterprise Plus-Instanzen unterstützt.

Hinweise

Wenn Sie das Google Cloud SDK verwenden möchten, müssen Sie Version 502.0.0 oder höher verwenden. Führen Sie gcloud --version aus, um die Version des Google Cloud SDK zu ermitteln. Führen Sie zum Aktualisieren des Google Cloud SDK gcloud components update aus.

Informationen zum Installieren des Google Cloud SDK finden Sie unter Installieren der gcloud CLI.

DR-Replikat bestimmen

Um eine erweiterte Notfallwiederherstellung durchzuführen, müssen Sie zuerst ein regionenübergreifendes DR-Replikat festlegen.

Anforderungen an primäre Instanzen

Die primäre Instanz muss eine Cloud SQL Enterprise Plus-Instanz sein und ein DR-Replikat haben.

Wenn Sie Ihre Cloud SQL-Instanz mit einem DNS-Schreibendpunkt (Vorabversion) erstellen, muss Ihre primäre Instanz dieselbe SSL-Konfiguration wie das angegebene Notfallwiederherstellungsreplikat haben, bevor Sie den Switchover- oder Replikations-Failovervorgang ausführen. Wenn Sie beispielsweise Ihr Notfallwiederherstellungsreplikat so konfigurieren, dass die SSL-Verschlüsselung erzwungen wird, die primäre Instanz aber unverschlüsselte Verbindungen zulässt, können Clients nach Abschluss des Umstiegs oder Failover-Vorgangs keine Verbindung mehr zur neuen primären Instanz herstellen.

Anforderungen an das DR-Replikat

Das festgelegte DR-Lesereplikat muss die folgenden Anforderungen erfüllen:

Muss eine Cloud SQL Enterprise Plus-Instanz sein
Kann nicht für Private Service Connect konfiguriert werden. Das Lesereplikat der DR kann jedoch für den Zugriff auf private Dienste konfiguriert werden.

Muss dieselbe Haupt- und Nebenversion der Datenbank wie die primäre Instanz sein, auf der MySQL 8.0.31 oder höher ausgeführt wird

Muss sich in einer anderen Region als die primäre Instanz befinden
Muss ein direktes Lesereplikat sein Darf kein kaskadierendes Replikat sein

Neben den Standardwerten kann für das DR-Replikat keines der folgenden Flags konfiguriert werden:
- replicate_do_db
- replicate_ignore_db
- replicate_do_table
- replicate_wild_do_table
- replicate_ignore_table
- replicate_wild_ignore_table

Muss die für PITR verwendeten Transaktionslogs in Cloud Storage speichern
Darf kein externes Replikat sein

Empfehlungen für das Replikat für Notfallwiederherstellung

Dieser Abschnitt enthält Empfehlungen für das DR-Replikat. Die folgenden Empfehlungen können helfen, Leistungsprobleme in Ihrer Bereitstellung zu vermeiden:

Verwenden Sie dieselbe Laufwerkgröße wie die primäre Instanz oder aktivieren Sie die automatische Vergrößerung.
Verwenden Sie eine konsistente Hochverfügbarkeitskonfiguration. Wenn Sie Hochverfügbarkeit auf der primären Instanz aktivieren, aktivieren Sie auch Hochverfügbarkeit auf dem DR-Replikat.
Verwenden Sie eine konsistente Datencache-Konfiguration. Wenn Sie den Datencache auf der primären Instanz aktivieren, müssen Sie auch den Datencache auf dem DR-Replikat aktivieren.
Konfigurieren Sie alle geeigneten Datenbank-Flags für Ihr DR-Replikat vor und nach Switchover- oder Replikat-Failover-Vorgängen.

Replikat erstellen, um die Anforderungen für DR-Replikate zu erfüllen

Wenn die primäre Instanz noch kein regionenübergreifendes Lesereplikat hat, das die Anforderungen der DR-Replikatdatenbank erfüllt, erstellen Sie eins.

Console

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

Cloud SQL-Instanzen aufrufen
Suchen Sie die primäre Instanz.
Klicken Sie in der Spalte Aktionenauf das Menü Weitere Aktionen.
Wählen Sie Lesereplikat erstellen aus.
Geben Sie im Feld Instanz-ID einen Namen für das DR-Replikat ein.
Im Feld Datenbankversion ist dieselbe Hauptversion der primären Instanz für Sie ausgewählt.
Wenn Sie MySQL 8.0 verwenden, belassen Sie im Feld Nebenversion die vorab ausgewählte Nebenversion. Das DR-Replikat und die primäre Instanz müssen dieselbe Datenbank-Nebenversion haben.
Führen Sie im Abschnitt Region und zonale Verfügbarkeit auswählen der Seite die folgenden Schritte aus:
- Wählen Sie eine andere Region als die Region Ihrer primären Instanz aus.
- Optional. Wählen Sie Mehrere Zonen für das DR-Replikat aus.
- Optional. Wählen Sie die primären und sekundären Zonen für das DR-Replikat aus.
Im Bereich Instanz anpassen der Seite können Sie die Einstellungen für das DR-Replikat ändern. Weitere Informationen zu den einzelnen Einstellungen finden Sie auf der Seite zu den Instanzeinstellungen.
Wählen Sie unter Maschinenformen den gleichen Maschinentyp wie Ihre primäre Instanz aus.
Konfigurieren Sie unter Flags alle Flags, die für Ihre Datenbank erforderlich sind.
Klicken Sie auf Replikat erstellen.

Cloud SQL erstellt eine Sicherung der primären Instanz und das Replikat. Sie werden dann zur Instanzseite der primären Instanz zurückgeleitet.

gcloud

Führen Sie den folgenden Befehl aus, um ein Replikat zu erstellen, das die Anforderungen eines DR-Replikats erfüllt:

gcloud sql instances create REPLICA_NAME \
   --master-instance-name=PRIMARY_INSTANCE_NAME \
   --region=REPLICA_REGION_NAME \
   --database-version=DATABASE_VERSION \
   --tier=MACHINE_TYPE \
   --availability-type=AVAILABILITY_TYPE
   --edition="ENTERPRISE_PLUS"

Ersetzen Sie die folgenden Variablen:

REPLICA_NAME: der Name des DR-Replikats
PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
REPLICA_REGION_NAME: Geben Sie eine Region an, die sich von der Region der primären Instanz unterscheidet.
DATABASE_VERSION: Geben Sie den Versionsstring an, der mit der Haupt- und Nebenversion der Datenbank der primären Instanz übereinstimmt, z. B. MYSQL_8_0_31.
Die Haupt- und Nebenversionen der Datenbank müssen für das primäre und das DR-Replikat identisch sein.
MACHINE_TYPE: Geben Sie denselben Maschinentyp wie die primäre Instanz an. Der Maschinentyp sollte mit dem Maschinentyp der primären Instanz übereinstimmen.
AVAILABILITY_TYPE: Wenn die primäre Instanz für Hochverfügbarkeit konfiguriert ist, empfehlen wir, REGIONAL anzugeben, um Hochverfügbarkeit zu aktivieren.
EDITION: Geben Sie ENTERPRISE_PLUS an.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
DATABASE_VERSION:-Versionsstring, der mit der Haupt- und Nebenversion der Datenbank der primären Instanz übereinstimmt, z. B. MYSQL_8_0_31. Die Datenbankversion muss für das primäre und das DR-Replikat identisch sein.
REPLICA_NAME: der Name der DR-Replikatinstanz, die Sie erstellen
REPLICA_REGION: die Region der DR-Replikatinstanz Die Replikatregion muss sich von der Region der primären Instanz unterscheiden.
MACHINE_TYPE: Geben Sie denselben Maschinentyp wie die primäre Instanz an. Es wird empfohlen, denselben Maschinentyp wie die primäre Instanz auszuwählen.
AVAILABILITY_TYPE: Wenn die primäre Instanz für Hochverfügbarkeit konfiguriert ist, empfehlen wir, REGIONAL anzugeben, um Hochverfügbarkeit zu aktivieren.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

JSON-Text anfordern:

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

curl (Linux, macOS oder Cloud Shell)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu haben Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt, die Sie automatisch bei der gcloud-Befehlszeile anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

curl -X POST \
     -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"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto bei der gcloud-Befehlszeile angemeldet haben. Dazu führen Sie gcloud init oder gcloud auth login aus. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

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

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
DATABASE_VERSION:-Versionsstring, der mit der Haupt- und Nebenversion der Datenbank der primären Instanz übereinstimmt, z. B. MYSQL_8_0_31. Die Datenbankversion muss für das primäre und das DR-Replikat identisch sein.
REPLICA_NAME: der Name der DR-Replikatinstanz, die Sie erstellen
REPLICA_REGION: die Region der DR-Replikatinstanz Die Replikatregion muss sich von der Region der primären Instanz unterscheiden.
MACHINE_TYPE: Geben Sie denselben Maschinentyp wie die primäre Instanz an. Wir empfehlen, dass die Laufwerksgröße mit der Laufwerksgröße der primären Instanz übereinstimmt.
AVAILABILITY_TYPE: Wenn die primäre Instanz für Hochverfügbarkeit konfiguriert ist, empfehlen wir, REGIONAL anzugeben, um Hochverfügbarkeit zu aktivieren.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances

JSON-Text anfordern:

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "DATABASE_VERSION",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "replicationType": "ASYNCHRONOUS",
  }
}

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

curl (Linux, macOS oder Cloud Shell)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

curl -X POST \
     -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"

PowerShell (Windows)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

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

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_UD/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

DR-Replikat für die primäre Instanz festlegen

Im Folgenden wird beschrieben, wie Sie eines der regionenübergreifenden Replikate einer primären Instanz als DR-Replikat für das Switchover oder das Replikat-Failover festlegen.

Console

So legen Sie ein DR-Replikat für eine primäre Instanz fest:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
Klicken Sie im Navigationsmenü auf Replikate.
Suchen Sie in der Liste der Lesereplikate das regionenübergreifende Lesereplikat, das Sie als DR-Replikat festlegen möchten.
Klicken Sie für das Replikat auf die Schaltfläche more_vert Aktionen und wählen Sie Als DR-Replikat festlegen aus.
Klicken Sie auf Bestätigen.

gcloud

Verwenden Sie den folgenden Befehl, um ein DR-Replikat zu einer primären Instanz festzulegen:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

Ersetzen Sie die folgenden Variablen:

PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
REPLICA_NAME: der Name des DR-Replikats

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

curl (Linux, macOS oder Cloud Shell)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

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/PRIMARY_INSTANCE_NAME"

PowerShell (Windows)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

$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/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Sie sollten in etwa folgende JSON-Antwort erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

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

curl (Linux, macOS oder Cloud Shell)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

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/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

PowerShell (Windows)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

$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/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Sie sollten in etwa folgende JSON-Antwort erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Kennzeichnung des DR-Replikats ändern

Wenn das Replikat die Anforderungen erfüllt, können Sie ein anderes Replikat als DR-Replikat festlegen. Das alte DR-Replikat verliert die Kennzeichnung des DR-Replikats.

Console

So ändern Sie das DR-Replikat für eine primäre Instanz:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
Klicken Sie im Navigationsmenü auf Replikate.
Suchen Sie in der Liste der Lesereplikate das regionenübergreifende Lesereplikat, das Sie als neues DR-Replikat festlegen möchten.
Klicken Sie für das Replikat auf die Schaltfläche more_vert Aktionen und wählen Sie Als DR-Replikat festlegen aus.

gcloud

Wenn Sie das DR-Replikat ändern möchten, führen Sie den Befehl noch einmal aus und geben Sie ein anderes DR-Replikat an.

REST

Wenn Sie das DR-Replikat ändern möchten, stellen Sie die API-Anfrage noch einmal und geben Sie ein anderes DR-Replikat an.

Kennzeichnung des DR-Replikats ansehen

Mit der gcloud CLI oder der Cloud SQL Admin API können Sie prüfen, welches DR-Replikat der primären Instanz zugewiesen ist. Sie können auch prüfen, ob ein Replikat ein festgelegtes DR-Replikat ist.

Gehen Sie so vor, um herauszufinden, welches DR-Replikat für eine primäre Instanz festgelegt wurde.

Console

So finden Sie heraus, welches Lesereplikat das festgelegte DR-Replikat für eine primäre Instanz ist:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
Klicken Sie im Navigationsmenü auf Replikate.
Prüfen Sie in der Liste der Lesereplikate, ob MySQL disaster recovery replica in der Spalte Typ für das festgelegte DR-Replikat angezeigt wird.

gcloud

Verwenden Sie den folgenden Befehl, um herauszufinden, welche Instanz das festgelegte DR-Replikat einer primären Instanz ist:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Ersetzen Sie die folgende Variable:

PRIMARY_INSTANCE_NAME: der Name der primären Instanz

Die Ausgabe dieses Befehls enthält das Feld failoverDrReplica, mit dem das festgelegte DR-Replikat angegeben wird.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_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/PRIMARY_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/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "MYSQL_8_0_31",
  "settings": {
  . . .
  "replicaNames": [
    "my-instance-replica"
  ],
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.5.4.1"
    }
  ],
  "instanceType": "CLOUD_SQL_INSTANCE",
   . . .
  "connectionName": "my-project:us-east1:my-instance",
  "name": "my-instance",
  "region": "us-east1",
  "gceZone": "us-east1-c",
  "secondaryGceZone": "us-east1-b",
  "databaseInstalledVersion": "MYSQL_8_0_31",
  "maintenanceVersion": "MYSQL_8_0_31.R20240207.00_07",
  "replicationCluster" {
       "failoverDrReplicaName": "my-project:my-instance-replica"
   },
  "createTime": "2024-03-15T18:11:03.596Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_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/v1beta4/projects/PROJECT_ID/instances/PRIMARY_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/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

{
  "kind": "sql#instance",
  "state": "RUNNABLE",
  "databaseVersion": "MYSQL_8_0_31",
  "settings": {
  . . .
  "replicaNames": [
    "my-instance-replica"
  ],
  "ipAddresses": [
    {
      "type": "PRIMARY",
      "ipAddress": "192.5.4.1"
    }
  ],
  "instanceType": "CLOUD_SQL_INSTANCE",
   . . .
  "connectionName": "my-project:us-east1:my-instance",
  "name": "my-instance",
  "region": "us-east1",
  "gceZone": "us-east1-c",
  "secondaryGceZone": "us-east1-b",
  "databaseInstalledVersion": "MYSQL_8_0_31",
  "maintenanceVersion": "MYSQL_8_0_31.R20240207.00_07",
  "replicationCluster" {
       "failoverDrReplicaName": "my-project:my-instance-replica"
   },
  "createTime": "2024-03-15T18:11:03.596Z",
  "sqlNetworkArchitecture": "NEW_NETWORK_ARCHITECTURE"
}
}

Mit einem der folgenden Verfahren können Sie prüfen, ob ein Replikat ein DR-Replikat ist.

Console

So prüfen Sie, ob eine Replikatinstanz ein DR-Replikat ist:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie die Replikatinstanz.
Prüfen Sie, ob MySQL disaster recovery replica in der Spalte Typ für das angegebene DR-Replikat angezeigt wird.

gcloud

Führen Sie den folgenden Befehl aus, um zu prüfen, ob eine Replikatinstanz ein DR-Replikat ist:

gcloud sql instances describe REPLICA_NAME

Ersetzen Sie die folgende Variable:

REPLICA_NAME: der Name des Lesereplikats, das Sie prüfen möchten

Wenn das Replikat ein DR-Replikat ist, enthält die Ausgabe des Befehls das Feld drReplica=true.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
REPLICA_NAME: der Name des Replikats

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_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/REPLICA_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/REPLICA_NAME" | Select-Object -Expand Content

Sie sollten einen erfolgreichen Statuscode (2xx) und eine leere Antwort als Ausgabe erhalten.

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
REPLICA_NAME: der Name des Replikats

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_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/REPLICA_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/REPLICA_NAME" | Select-Object -Expand Content

Sie sollten einen erfolgreichen Statuscode (2xx) und eine leere Antwort als Ausgabe erhalten.

DR-Replikat entfernen

Sie können die Kennzeichnung des DR-Replikats von einer primären Instanz löschen. Wenn jedoch einer primären Instanz kein DR-Replikat zugewiesen ist, können Sie keinen Switchover und kein Replikat-Failover ausführen.

Console

So entfernen Sie ein festgelegtes DR-Replikat aus einer primären Instanz:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie die primäre Instanz und wählen Sie sie aus. Die Seite Übersicht für die primäre Instanz wird angezeigt.
Klicken Sie im Navigationsmenü auf Replikate.
Suchen Sie in der Liste der Lesereplikate das regionenübergreifende Lesereplikat, das Sie entfernen möchten.
Klicken Sie für das Replikat auf die Schaltfläche more_vert Aktionen und wählen Sie Als DR-Replikat entfernen aus.
Klicken Sie auf Bestätigen.

gcloud

Führen Sie den folgenden Befehl auf der primären Instanz aus, um die Kennzeichnung des DR-Replikats zu entfernen:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

Ersetzen Sie die folgende Variable:

PRIMARY_INSTANCE_NAME: der Name der primären Instanz, aus der Sie das festgelegte DR-Replikat entfernen möchten

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
Setzen Sie das Feld failoverDrReplicaName auf einen leeren String.

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

curl (Linux, macOS oder Cloud Shell)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

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/PRIMARY_INSTANCE_NAME"

PowerShell (Windows)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

$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/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Sie sollten in etwa folgende JSON-Antwort erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
PRIMARY_INSTANCE_NAME: Der Name der primären Instanz.
Setzen Sie das Feld failoverDrReplicaName auf einen leeren String.

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

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

curl (Linux, macOS oder Cloud Shell)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

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/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME"

PowerShell (Windows)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

$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/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME" | Select-Object -Expand Content

Sie sollten in etwa folgende JSON-Antwort erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T21:30:35.667Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Switchover durchführen

Nachdem Sie ein DR-Replikat festgelegt haben, können Sie den Switchover-Vorgang ausführen. Als Best Practice sollten Sie den Switchover-Vorgang jedoch unter den folgenden Umständen vermeiden:

Die primäre Instanz wird aktiv verwendet.
Administratorvorgänge werden ausgeführt, z. B. die automatische Sicherung oder die Aktivierung oder Deaktivierung der Hochverfügbarkeit (High Availability, HA).

Führen Sie einen Switchover durch, wenn das Transaktionsvolumen niedrig ist, um eine Zeitüberschreitung zu vermeiden.

Nach Abschluss des Switchovers wird die Sicherung der neuen primären Instanz (dem vorherigen DR-Replikat) erstellt, sobald die neue primäre Instanz hochgestuft wird. Nach Abschluss dieser Sicherung ist die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-Time-Recovery, PITR) auf der neuen primären Instanz vollständig aktiviert. Diese Sicherung kann je nach Laufwerkgröße zwischen 5 und 15 Minuten dauern. Die PITR-Abdeckung beginnt erst, wenn diese Sicherung abgeschlossen wurde. Weitere Informationen zur Verwendung von PITR mit erweiterter DR finden Sie unter PITR mit erweiterter DR verwenden.

Nach Abschluss des Switchover-Vorgangs werden Sie feststellen, dass die Richtung der Replikation umgekehrt wird.

Nachdem die alte primäre Instanz als Lesereplikat neu konfiguriert wurde, wird der DNS-Schreibendpunkt, der zuvor auf die alte primäre Instanz verweiste, auf die neue primäre Instanz umgeleitet.

Hinweise

Führen Sie die folgenden Schritte aus, bevor Sie den Switchover-Vorgang ausführen:

Legen Sie ein DR-Replikat fest. Sie können nur ein Switchover zwischen der primären Instanz und dem angegebenen DR-Replikat ausführen.
Prüfen Sie, ob die primäre Instanz und das DR-Replikat online sind.
Wenn Sie einen DNS-Schreibendpunkt verwenden, prüfen Sie, ob die SSL-Konfiguration für die primäre Instanz und das DR-Replikat identisch ist. Wenn das DR-Replikat beispielsweise so konfiguriert ist, dass SSL-Verschlüsselung erzwungen wird, die primäre Instanz aber unverschlüsselte Verbindungen zulässt, können Clients nach Abschluss des Switchover-Vorgangs keine Verbindung mehr zur neuen primären Instanz herstellen.
Erstellen Sie eine On-Demand-Sicherung der primären Instanz. Diese Sicherung ist eine Vorsichtsmaßnahme, falls Sie nach einem unerwarteten Fehler eine Wiederherstellung durchführen müssen.

Switchover-Vorgang ausführen

Console

So führen Sie den Switchover-Vorgang aus:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie das festgelegte DR-Replikat der primären Instanz.
Klicken Sie auf die DR-Replikatinstanz. Die Seite Übersicht für das DR-Replikat wird angezeigt.
Klicken Sie auf die Schaltfläche Wechseln.
Geben Sie auf der Seite Switchover zwischen dem primären und dem DR-Replikat den Namen der primären Instanz in das Feld Instanz-ID ein.
Klicken Sie auf Umstellung.

gcloud

Führen Sie den folgenden Befehl aus, um den Switchover auszuführen:

gcloud sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

Ersetzen Sie die folgenden Variablen:

REPLICA_NAME: der Name des festgelegten DR-Replikats, mit dem die primäre Instanz die Rollen wechseln soll.
TIMEOUT_DURATION: Optional. Das Zeitlimit, um den Abschluss der Datenbankvorgänge auf der Instanz zu ermöglichen

Wenn Sie diesen Parameter nicht angeben, enthält der Umschaltvorgang ein Zeitlimit von 10 Minuten.

Sie können den Wert dieses Zeitlimits erhöhen, indem Sie den Parameter --db-timeout angeben. Ersetzen Sie TIMEOUT_DURATION durch eine Zeitraumdauer von bis zu 24 Stunden, einschließlich einer Anfangsschreibweise für das Format. Geben Sie beispielsweise für 30 Sekunden 30s an. Für 24 Stunden geben Sie 24h an. Sie können auch Brucheinheiten des Zeitraums mit Dezimalzahlen mit bis zu neun Stellen angeben. Geben Sie beispielsweise für 30,5 Minuten 30.5m an.

Wenn keine ausstehenden Vorgänge vorhanden sind, können Sie den Wert dieses Zeitlimits verringern.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

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 POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Führen Sie folgenden Befehl aus:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
REPLICA_NAME: der Name des DR-Replikats

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

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 POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Führen Sie folgenden Befehl aus:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Notfallwiederherstellung durch Aufruf eines Replikat-Failovers ausführen

Bei einem regionalen Ausfall oder einem Notfall können Sie die Notfallwiederherstellung durchführen, indem Sie einen Replikat-Failover-Vorgang zu dem vorgesehenen DR-Replikat aufrufen. Für ein Replikat-Failover stufen Sie das festgelegte DR-Replikat hoch. Im Gegensatz zur Umstellung erfolgt das Hochstufen des DR-Replikats sofort.

Da das DR-Replikat die Rolle der primären Instanz sofort übernimmt, ist es möglich, dass das Replikat aufgrund der Replikationsverzögerung nicht alle Daten aus der alten primären Instanz hat. Aus diesem Grund kann bei einem Replikat-Failover Datenverluste auftreten.

Im Rahmen des Hochstufungsprozesses erstellt das Replikat-Failover eine Sicherung der neuen primären Instanz (dem vorherigen DR-Replikat), sobald das DR-Replikat zur neuen primären Instanz wird. Nach Abschluss der Sicherung ist die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-In-Time Recovery, PITR) auf der neuen primären Instanz vollständig aktiviert. Diese Sicherung kann je nach Laufwerkgröße der neuen (und alten) primären Instanz zwischen 5 und 15 Minuten dauern. Während dieses Sicherungszeitraums ist PITR nicht verfügbar.

Sobald die alte primäre Instanz wieder online ist, erstellt der Replikat-Failover-Prozess eine Sicherung. Nachdem diese Sicherung erstellt wurde, wird die alte primäre Instanz als Lesereplikat der neuen primären Instanz neu erstellt.

Weitere Informationen zur Verwendung von PITR mit erweiterter DR finden Sie unter PITR mit erweiterter DR verwenden.

Nachdem Sie den Replikat-Failover-Vorgang aufgerufen haben, wird der DNS-Schreibendpunkt, der zuvor auf die alte primäre Instanz verweiste, auf die neue primäre Instanz aufgelöst.

Hinweise

Führen Sie die folgenden Schritte aus, bevor Sie ein Replikat-Failover ausführen können:

Legen Sie ein DR-Replikat fest, falls noch nicht geschehen. Sie können ein Replikat-Failover nur zwischen der primären Instanz und dem angegebenen DR-Replikat ausführen.
Sorgen Sie dafür, dass das DR-Replikat online und fehlerfrei ist.

Replikat-Failover-Vorgang ausführen

Console

So führen Sie den Replikat-Failover-Vorgang aus:

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

Cloud SQL-Instanzen aufrufen
Suchen Sie das festgelegte DR-Replikat der primären Instanz.
Klicken Sie auf die DR-Replikatinstanz. Die Seite Übersicht für das DR-Replikat wird angezeigt.
Klicken Sie auf die Schaltfläche Replikat-Failover.
Geben Sie auf der Seite Replikat-Failover zwischen dem primären und dem DR-Replikat ausführen den Namen der primären Instanz in das Feld Instanz-ID ein. Damit bestätigen Sie, dass Sie mit dem Vorgang fortfahren möchten.
Klicken Sie zum Starten des Replikat-Failovers auf Replikat-Failover.

gcloud

Verwenden Sie den folgenden Befehl, um ein Replikat-Failover zum DR-Replikat aufzurufen:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Ersetzen Sie die folgende Variable:

REPLICA_NAME: der Name des DR-Replikats

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
REPLICA_NAME: der Name des DR-Replikats
ENABLE_REPLICA_FAILOVER: Legen Sie true fest, um das Replikat-Failover zu verwenden. Wenn Sie false festlegen, verwendet die API die reguläre promoteReplica-Methode ohne Replikat-Failover.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

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 POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Führen Sie folgenden Befehl aus:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts der primären Instanz und des DR-Replikats
REPLICA_NAME: der Name des DR-Replikats
ENABLE_REPLICA_FAILOVER: Legen Sie true fest, um das Replikat-Failover zu verwenden. Wenn Sie false festlegen, verwendet die API die reguläre promoteReplica-Methode ohne Replikat-Failover.

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

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 POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Führen Sie folgenden Befehl aus:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Antwort

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Status eines Replikat-Failovers prüfen

Das Replikat-Failover erfolgt in zwei Phasen. Die erste Phase ist die Hochstufung des DR-Replikats. In der zweiten Phase wird die alte primäre Instanz als Lesereplikat wiederhergestellt.

Prüfen Sie den Status der einzelnen Phasen, um den Status des Replikat-Failovers zu prüfen.

Prüfen Sie den Status der ersten Phase.
Console

So prüfen Sie, ob das DR-Replikat zu einer eigenständigen Instanz hochgestuft wurde:
1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
  
  Cloud SQL-Instanzen aufrufen
2. Suchen Sie den Namen des DR-Replikats, das Sie hochgestuft haben.
3. Prüfen Sie, ob MySQL VERSION in der Spalte Typ für die neue primäre Instanz angezeigt wird.
gcloud
Sie können den Status prüfen, indem Sie den folgenden Befehl ausführen:
```
gcloud sql instances describe DR_REPLICA_NAME
```
Ersetzen Sie die folgende Variable:
- DR_REPLICA_NAME ist der Name des hochgestuften DR-Replikats.
Prüfen Sie in der Ausgabe, ob das folgende Feld angezeigt wird und das Replikat zu einer eigenständigen Cloud SQL-Instanz geworden ist:
```
instanceType: CLOUD_SQL_INSTANCE
```
Prüfen Sie im Vorgangslog der Instanz auf die Meldung RECONFIGURE_OLD_PRIMARY, um den Abschluss der zweiten Phase zu prüfen.

Die Darstellung dieser Nachricht hängt davon ab, wann die alte primäre Instanz online ist. Dies kann im Notfall einige Minuten oder Tage dauern.

Weitere Informationen zum Prüfen der Vorgangslogs für eine Instanz finden Sie unter Instanzlogs ansehen.

PITR mit erweiterter Notfallwiederherstellung verwenden

Sowohl beim Switchover als auch beim Replikat-Failover werden die folgenden Änderungen vorgenommen, um die Sicherung und PITR zu unterstützen, sobald das DR-Replikat zu einer primären Instanz hochgestuft wird:

Die Sicherungskonfiguration, einschließlich der automatischen Sicherungsplanung, wird von der alten primären Instanz in die neue primäre Instanz kopiert.

Wenn diese Option deaktiviert ist, wird das binlog-Konfigurations-Flag aktiviert, um PITR zu aktivieren.

Eine neue Sicherung wird erstellt, um PITR auf der neuen primären Instanz zu unterstützen.
Die Aufbewahrungsrichtlinie des Transaktionslogs wird von der alten primären Instanz zur neuen primären Instanz kopiert.

Sowohl für die Sicherungskonfiguration als auch für die Aufbewahrungsrichtlinien der Transaktionslogs sollten Sie überprüfen, ob die von der alten primären Instanz übernommenen Einstellungen für die neue primäre Instanz korrekt sind.

Beginn der PITR-Abdeckung

Am Ende des Switchover-Vorgangs plant Cloud SQL automatische Sicherungen und erstellt die erste Sicherung der neuen primären Instanz. Wenn Sie möchten, dass die PITR-Abdeckung früher als später beginnt, sollten Sie prüfen, ob die erste Sicherung erfolgreich war. Die neu hochgestufte primäre Instanz hat die PITR-Abdeckung erst, nachdem die erste automatische Sicherung erfolgreich abgeschlossen wurde.

Weitere Informationen zum Aufrufen der Sicherungen, die für eine Instanz verfügbar sind, finden Sie unter Liste der Sicherungen ansehen.

PITR-Abdeckung für Instanzen während des Switchovers und des Replikat-Failover

Wenn eine Instanz an einem Switchover oder einem Replikat-Failover-Vorgang beteiligt ist, verbringt die Instanz Zeit als Lesereplikat. PITR und die Wiederherstellung einer Sicherung werden während des Zeitraums unterstützt, in dem die Instanz als Lesereplikat und als primäre Instanz verwendet wird.

Sie können die PITR zu einem Zeitpunkt vor dem Switchover ausführen, als die Instanz noch eine primäre Instanz war. Sowohl beim Switchover als auch beim Replikat-Failover wird in Cloud SQL eine Best-Effort-Sicherung für die neue primäre Instanz gestartet, sobald die neue primäre Instanz hochgestuft wird. PITR wird erst nach Abschluss dieser Sicherung auf der hochgestuften Instanz aktiviert. Diese Sicherung kann je nach Laufwerkgröße zwischen 5 und 15 Minuten dauern.

Split-Brain bei Replikat-Failover

Es kann zu einer Splitbrain-Situation kommen, wenn die primäre Instanz weiterhin Schreibvorgänge akzeptiert, während ein Replikat mithilfe des Replika-Failovers hochgestuft wird. Nachdem das Replikat hochgestuft wurde und die alte primäre Instanz wieder verfügbar ist, wird sie als Replikat der hochgestuften Instanz neu erstellt und eine endgültige Sicherung erstellt. Mit dieser Sicherung können alle Split-Brain-Daten wiederhergestellt werden, die nicht in das beförderte Replikat geschrieben wurden.

Sicherungen und Transaktionslogs auf Replikaten löschen

Wenn eine primäre Instanz, die mit PITR aktiviert wurde, und Sicherungen zu einem Lesereplikat wird, wird die letzte Sicherung und PITR-Aufbewahrungsrichtlinie ab ihrer Zeit als primäre Instanz beibehalten und während ihrer Zeit als Replikat angewendet. Auch wenn die neue primäre Instanz keine Sicherungen erstellt, werden die alten Sicherungen und Transaktionslogs, die für PITR verwendet werden, gemäß der zuletzt konfigurierten Richtlinie auf dem Lesereplikat gelöscht.

Wenn die Instanz beispielsweise für tägliche automatische Sicherungen konfiguriert ist und sieben Sicherungen mit sieben Tagen PITR-Logs speichert, werden alle Daten, die älter als sieben Tage sind, einmal täglich gelöscht, sobald diese Instanz zu einem Lesereplikat wird.

Wenn Sie Sicherungen früher löschen müssen, können Sie diese manuell entfernen. Weitere Informationen finden Sie unter Sicherung löschen.

Beschränkungen

Die erweiterte Notfallwiederherstellung wird für Cloud SQL-Instanzen, die Private Service Connect verwenden, nicht unterstützt. Die erweiterte Notfallwiederherstellung unterstützt den Zugriff auf private Dienste.
Sie können eine Lesereplikatinstanz der Cloud SQL Enterprise Plus-Version nicht als DR-Replikat festlegen, wenn die primäre Instanz ihre Transaktionslogs für die Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) auf dem Laufwerk speichert. Informationen zum Prüfen, wo eine Instanz ihre Logs für PITR speichert, finden Sie unter Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden.
Sie können ein externes Replikat nicht als DR-Replikat festlegen.
Terraform wird für Switchover- oder Replikat-Failover-Vorgänge nicht unterstützt.

Fehlerbehebung

Problem	Fehlerbehebung
Der Umschaltvorgang ist fehlgeschlagen.	Prüfen Sie, ob die Instanz alle angegebenen Anforderungen für das DR-Replikat erfüllt. Prüfen Sie die Anzahl der Transaktionen in der Datenbank. Der Switchover sichert die binären Logs der primären Instanz in Cloud Storage, bevor er den Switchover durchführt. Wenn das Transaktionsvolumen hoch ist, kann dies zu einer Zeitüberschreitung des Vorgangs führen. Versuchen Sie, den Vorgang zu wiederholen, wenn die Transaktionslast geringer ist.
Der Umschaltvorgang ist fehlgeschlagen und die primäre Instanz bleibt im schreibgeschützten Modus.	Führen Sie einen Neustart der Datenbank durch, um sie wieder in den Schreibmodus zu versetzen.
Der Umschaltvorgang ist abgeschlossen, aber in der Google Cloud Console werden die neuen umgekehrten Rollen für die Instanzen nicht angezeigt.	Aktualisieren Sie Ihren Browser, um die aktualisierte Topologie anzuzeigen.
Der Replikat-Failover-Vorgang ist fehlgeschlagen.	Sorgen Sie dafür, dass ein DR-Replikat für die primäre Instanz festgelegt ist und online ist. Wenn das Failover auf das DR-Replikat fehlgeschlagen ist, stufen Sie stattdessen zu einem regulären (Nicht-DR-) Lesereplikat hoch.
Ich kann nicht erkennen, ob die Replikation nicht erfolgt	Stellen Sie eine Verbindung zum Replikat her und geben Sie Folgendes ein: show slave status; Wenn die Replikation erfolgt, wird in der ersten Spalte „`Slave_IO_State`“ der Wert `Waiting for master to send event` angezeigt und das Feld „`Last_IO_Error`“ ist leer. Wenn die Replikation nicht erfolgt, wird in der ersten Spalte `"Slave_IO_State"` der Eintrag `"Connecting to master"` angezeigt. und das Feld `"Last_IO_Error"` einen Fehler wie `"error connecting to master 'cloudsqlreplica@x.x.x.x:3306"` anzeigt. Sie können den Replikationsstatus der Replikate auch im Cloud SQL-Monitoring-Dashboard aufrufen. Weitere Informationen finden Sie unter Cloud SQL-Instanzen überwachen.
Sie haben die folgende Fehlermeldung erhalten: `"Instance was converted into a replica between the target PITR time and the last available base backup. PITR logs are not available for the period instance was a replica. Please clone from the instance that was primary at time %s"`	Sie können PITR nicht für einen Zeitraum ausführen, in dem eine Instanz auf ein Replikat umgestellt wurde. Die PITR-Logs sind nicht für den Zeitraum verfügbar, in dem die Instanz ein Replikat war. Überprüfen Sie die Liste der Vorgänge für die Instanz, um festzustellen, ob die Instanz zu diesem Zeitpunkt ein Replikat war. Ermitteln Sie anhand der Liste der Vorgänge, welche Instanz zu diesem Zeitpunkt die primäre Instanz war. Klonen Sie diese Instanz, um PITR auszuführen.
Sie haben die folgende Fehlermeldung erhalten: `"You can only designate a disaster recovery (DR) replica for primary instances that are storing their PITR logs in Cloud Storage. PITR logs of the instance %s are not stored in Cloud Storage"`	Die primäre Instanz hat den Speicherort für ihre Transaktionslogs noch nicht auf Cloud Storage geändert. Sie können es noch einmal versuchen, nachdem der Speicherort für die Transaktionslogs geändert wurde, oder ein DR-Replikat für eine andere primäre Instanz festlegen. Weitere Informationen zum Verschieben des Speicherorts der für PITR verwendeten Transaktionslogs finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt verwenden.
Sie haben die folgende Fehlermeldung erhalten: `"The specified failover dr replica name REPLICA_NAME must be one of the replicas of the primary instance INSTANCE_NAME`."	Weitere Informationen zum Festlegen eines DR-Replikats und zur korrekten Befehlssyntax finden Sie unter DR-Replikat für die primäre Instanz festlegen.