Lesereplikate erstellen

Auf dieser Seite wird gezeigt, wie ein Lesereplikat für eine Cloud SQL-Instanz erstellt wird.

Ein Lesereplikat ist die Kopie einer primären Instanz, die Änderungen der primären Instanz nahezu in Echtzeit abbildet. Mit einem Lesereplikat können Sie Folgendes tun:

  • Leseanfragen oder Analysedatentraffic von der primären Instanz entfernen
  • Zur Notfallwiederherstellung eine regionale Migration oder ein Failover in eine andere Region ausführen (wenn das Replikat ein regionenübergreifendes Replikat ist, also in einer Region erstellt wurde, die von der primären Instanz verschieden ist).

Weitere Informationen zur Funktionsweise von Replikaten finden Sie unter Replikation in Cloud SQL.

Hinweis

Achten Sie beim Erstellen des ersten Replikats für diese Instanz darauf, dass die Instanz die Anforderungen für primäre Instanzen erfüllt. Mehr erfahren

Lesereplikat erstellen

Im Folgenden werden die Schritte zum Erstellen eines Lesereplikats dargestellt.

Konsole

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

    Zur Seite „Cloud SQL-Instanzen“

  2. Suchen Sie die Instanz, für die Sie ein Replikat erstellen möchten, und öffnen Sie das Menü more actions ganz rechts in der Liste.
  3. Wählen Sie Lesereplikat erstellen aus.

    Ist diese Option nicht vorhanden, ist die Instanz bereits ein Replikat. Sie können kein Replikat eines Replikats erstellen.

  4. Wenn für die Instanz Sicherungen und binäres Logging aktiviert sind, fahren Sie mit Schritt 6 fort. Andernfalls wählen Sie Automatische Sicherungen und Binäres Logging aktivieren aus. Klicken Sie auf Weiter und dann auf Speichern und neu starten, um die Instanz neu zu starten.

    Durch die Aktivierung des binären Loggings wird die Instanz neu gestartet.

  5. Aktualisieren Sie auf der Seite Lesereplikat erstellen gegebenenfalls die Instanz-ID sowie alle anderen erforderlichen Konfigurationsoptionen, einschließlich Name, Region und Zone.
  6. Klicken Sie auf Erstellen.

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

gcloud

  1. Prüfen Sie den Status der primären Instanz:
    gcloud sql instances describe
          PRIMARY_INSTANCE_NAME
          

    Wenn das Attribut databaseReplicationEnabled den Wert true hat, ist die Instanz ein Replikat. Sie können kein Replikat eines Replikats erstellen.

  2. Wenn das Attribut enabled unter backupConfiguration den Wert false hat, aktivieren Sie jetzt die Sicherungen für die primäre Instanz:
    gcloud sql instances patch
          PRIMARY_INSTANCE_NAME --backup-start-time >HH:MM
          
    Der Parameter backup-start-time wird im 24-Stunden-Format in der Zeitzone UTC±00 festgelegt und definiert den Beginn eines vierstündigen Sicherungszeitraums. Die Sicherungen können zu einem beliebigen Zeitpunkt innerhalb dieses Sicherungszeitraums gestartet werden.
  3. Wenn das Attribut binaryLogEnabled den Wert false hat, aktivieren Sie binäre Logs auf der primären Instanz:
    gcloud sql instances patch --enable-bin-log PRIMARY_INSTANCE_NAME
    Durch Aktivierung der binären Logs wird die Instanz neu gestartet.
  4. Erstellen Sie das Replikat:
    gcloud sql instances create REPLICA_NAME --master-instance-name=PRIMARY_INSTANCE_NAME
    

    Bei Bedarf können Sie mithilfe des Parameters --tier eine andere Ebenengröße angeben.

    Mit dem Parameter --region können Sie eine andere Region angeben.

    Wenn die primäre Instanz nur eine private IP-Adresse hat, fügen Sie dem Befehl den Parameter --no-assign-ip hinzu.

    Sie müssen das Replikat im selben VPC-Netzwerk wie die primäre Instanz erstellen.

  • Binäres Logging wird für Lesereplikatinstanzen unterstützt (nur MySQL 5.7 und 8.0). Wird auf Legacy-HA-Failover-Replikaten nicht unterstützt.) Aktivieren Sie binäres Logging in einem Replikat mit demselben gcloud-Befehl. Verwenden Sie dabei den Instanznamen des Replikats anstelle des Instanznamens der primären Instanz.
    gcloud sql instances patch --enable-bin-log REPLICA_INSTANCE_NAME
        

    Die Langlebigkeit des binären Loggings im Replikat (aber nicht auf der primären Instanz) kann mit dem Flag sync_binlog festgelegt werden. Damit wird gesteuert, wie oft der MySQL-Server das binäre Log mit dem Laufwerk synchronisiert.

    Sicherungen können nicht auf Replikatinstanzen aktiviert werden. Binäres Logging kann jedoch im Gegensatz zur primären Instanz auch dann für ein Replikat aktiviert werden, wenn Sicherungen deaktiviert sind.

    Die binlog-Aufbewahrungsdauer für Replikatinstanzen wird automatisch auf einen Tag eingestellt, im Gegensatz zu sieben Tagen bei primären Instanzen.

REST API v1beta4

  1. Aktuelle Sicherungskonfiguration abrufen

    Mit der get-Methode der Instanzressource rufen Sie die Datenbankversion und die aktuelle Sicherungskonfiguration für den Master ab.

    Ersetzen Sie diese Werte in den folgenden Anweisungen:

    • project-id: Die Projekt-ID
    • primary-instance-name: Der Name der primären Instanz

    HTTP-Methode und URL:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/primary-instance-name

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

    Sie sollten in etwa folgende JSON-Antwort erhalten:

  2. Festlegung der Replikationsfelder prüfen

    Wenn entweder enabled oder binaryLogEnabled auf der primären Instanz den Wert false hat, verwenden Sie die patch-Methode der Instanzressource, um beide auszuwählen. Geben Sie in der Anfrage alle Attribute der Sicherungskonfiguration an, die Sie ändern möchten.

    Geben Sie zum Aktivieren von Sicherungen für enabled den Wert true und für startTime eine Tageszeit im Format HH:MM an. Der Parameter startTime wird im 24-Stunden-Format in der Zeitzone UTC±00 festgelegt und definiert den Beginn eines vierstündigen Sicherungszeitraums. Die Sicherungen können zu einem beliebigen Zeitpunkt innerhalb dieses Sicherungszeitraums gestartet werden.

    Wenn Sie die Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren möchten, legen Sie für binaryLogEnabled den Wert true auf der primären Instanz fest.

    Binäres Logging wird für Lesereplikatinstanzen unterstützt (nur MySQL 5.7 und 8.0). Aktivieren Sie binäres Logging in einem Replikat mit derselben API. Verwenden Sie dabei die Instanz-ID des Replikats anstelle der Instanz-ID der primären Instanz.

    Die Langlebigkeit des binären Loggings im Replikat (aber nicht auf der primären Instanz) kann mit dem Flag sync_binlog festgelegt werden. Damit wird gesteuert, wie oft der MySQL-Server das binäre Log mit dem Laufwerk synchronisiert.

    Sicherungen können nicht auf Replikatinstanzen aktiviert werden. Binäres Logging kann jedoch im Gegensatz zur primären Instanz auch dann für ein Replikat aktiviert werden, wenn Sicherungen deaktiviert sind.

    Ersetzen Sie diese Werte in den folgenden Anweisungen:

    • project-id: die Projekt-ID
    • instance-id: die Instanz-ID (primäre oder Replikatinstanz)
    • start-time: die Uhrzeit im Format „HH:MM“
    • enabled: bei einer primären Instanz auf „true“ und bei einer Replikatinstanz auf „false“ setzen

    HTTP-Methode und URL:

    PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

    JSON-Text anfordern:

    {
      "settings":
      {
        "backupConfiguration":
        {
          "startTime": "start-time",
          "enabled": enabled,
          "binaryLogEnabled": true
        }
      }
    }
    

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

    Sie sollten in etwa folgende JSON-Antwort erhalten:

  3. Lesereplikat erstellen

    Mit der Methode insert der Instanzressource erstellen Sie das Lesereplikat. Das Attribut databaseVersion muss mit der primären Instanz übereinstimmen. Legen Sie für ein regionenübergreifendes Lesereplikat eine andere Region als die Region der primären Instanz fest.

    Geben Sie für die Parameter folgende Werte an:

    • project-id: die Projekt-ID
    • database-version: String der Enum-Version (z. B. MYSQL_8_0)
    • primary-instance-name: Der Name der primären Instanz
    • primary-instance-region: Die Region der primären Instanz
    • replica-region: Die Region der Replikatinstanz
    • replica-name: der Name der Replikatinstanz
    • machine-type: Enum-String des Maschinentyps Beispiel: „db-custom-1-3840”

    HTTP-Methode und URL:

    POST https://sqladmin.googleapis.com/sql/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",
        "settingsVersion": 0,
      }
    }
    

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

    Sie sollten in etwa folgende JSON-Antwort erhalten:

Lesereplikate für die IAM-Datenbankauthentifizierung konfigurieren

Bei Lesereplikaten ist das Flag cloudsql.iam_authentication nicht automatisch aktiviert, wenn es auf der primären Instanz aktiviert wird.

So konfigurieren Sie ein Lesereplikat für die Authentifizierung einer IAM-Datenbank:

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

    Zur Seite „Cloud SQL-Instanzen“

  2. Klicken Sie auf den Namen der primären Instanz.
  3. Suchen Sie in der Konfigurationskachel nach dem Flag cloudsql.iam_authentication. Wenn das Flag nicht in der Liste enthalten ist, ist es nicht nötig, das Flag im Lesereplikat zu aktivieren. Befindet sich das Flag in der Liste, müssen Sie das Flag für das Lesereplikat aktivieren. Wenn Sie das Flag für das Lesereplikat aktivieren müssen, fahren Sie mit dem nächsten Schritt fort.
  4. Wählen Sie im linken Navigationsbereich Replikate aus.
  5. Klicken Sie auf den Namen des Replikats, das Sie bearbeiten möchten.
  6. Klicken Sie auf BEARBEITEN.
  7. Maximieren Sie unter Konfigurationsoptionen den Eintrag Flags.
  8. Wählen Sie + Hinzufügen aus.
  9. Geben Sie als Flag-Namen cloudsql.iam_authentication ein. Achten Sie darauf, dass für dieses Flag An ausgewählt ist.
  10. Klicken Sie auf Speichern.

Fehlerbehebung

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Beim Erstellen hat das Lesereplikat nicht repliziert. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler Eines der explizit oder standardmäßig angegebenen Flags ist ungültig. Prüfen Sie Flag-Werte und Logs auf weitere Informationen.
Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Laufwerk ist voll. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Aktualisieren Sie die primäre Instanz mit einem größeren Laufwerk.
Replikatinstanz verwendet zu viel Arbeitsspeicher. Replikate können häufig angeforderte Lesevorgänge im Cache speichern. Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.
Replikation gestoppt. Der maximale Speicherplatz wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert. Aktivieren Sie die automatische Speichererweiterung.
Replikationsverzögerung ist durchgehend hoch. Die kann viele verschiedene Ursachen haben. Hier finden Sie einige Lösungsvorschläge.

Beim Erstellen hat das Lesereplikat nicht repliziert

Beim Erstellen hat das Lesereplikat nicht repliziert.

Mögliche Ursache

Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler.

Lösungsvorschlag

Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.


Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler

Das Lesereplikat kann nicht erstellt werden – invalidFlagValue.

Mögliche Ursache

Eines der Flags in der Anfrage ist ungültig. Dies kann ein Flag sein, das Sie explizit angegeben haben, oder ein Flag, für das ein Standardwert festgelegt wurde.

Lösungsvorschlag

Prüfen Sie als Erstes, ob der Wert des Flags max_connections größer oder gleich dem Wert auf der Primärseite ist.

Wenn das Flag max_connections korrekt festgelegt ist, prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.


Lesereplikat kann nicht erstellt werden – unbekannter Fehler

Das Lesereplikat kann nicht erstellt werden – unknown error.

Mögliche Ursache

Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler.

Lösungsvorschlag

Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.

Lautet der Fehler set Service Networking service account as servicenetworking.serviceAgent role on consumer project, deaktivieren Sie die Service Networking API und aktivieren Sie sie dann wieder. Dadurch wird das Dienstkonto erstellt, das erforderlich ist, um den Prozess fortzusetzen.


Laufwerk voll

UPDATE_DISK_SIZE- oder mysqld: disk is full-Fehler.

Mögliche Ursache

Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden.

Lösungsvorschlag

Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.


Replikatinstanz verwendet zu viel Arbeitsspeicher

Die Replikatinstanz verwendet zu viel Arbeitsspeicher.

Mögliche Ursache

Das Replikat verwendet temporären Speicher zum Speichern häufig angeforderter Lesevorgänge im Cache, was dazu führen kann, dass es mehr Speicher als die primäre Instanz verwendet.

Lösungsvorschlag

Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.


Replikation gestoppt

Die Replikation wurde gestoppt.

Mögliche Ursache

Das maximale Speicherlimit wurde erreicht und >automatic storage increase is disabled.

Lösungsvorschlag

Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.


Replikationsverzögerung ist durchgehend hoch

Die Replikationsverzögerung ist durchgehend hoch.

Mögliche Ursache

Die Schreiblast ist für das Replikat zu hoch. Die Replikationsverzögerung tritt auf, wenn der SQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:

  • Langsame Abfragen des Replikats. Suchen Sie diese und korrigieren Sie sie.
  • Alle Tabellen müssen einen eindeutigen Schlüssel/Primärschlüssel haben. Jede Aktualisierung einer solchen Tabelle ohne eindeutigen bzw. Primärschlüssel führt zu vollständigen Tabellenscans auf dem Replikat.
  • Abfragen wie DELETE ... WHERE field < 50000000 führen bei der zeilenbasierten Replikation zu einer Replikationsverzögerung, da sich eine große Anzahl von Aktualisierungen auf dem Replikat ansammelt.

Lösungsvorschlag

Mögliche Lösungen:

Nächste Schritte