Replikation in Cloud SQL

Durch Replikation können Kopien einer Cloud SQL-Instanz oder einer lokalen Datenbank erstellt und die Arbeit auf die Kopien übertragen werden.

Einführung

Der Hauptgrund für die Verwendung der Replikation besteht darin, die Nutzung von Daten in einer Datenbank zu skalieren, ohne dabei die Leistung zu beeinträchtigen. Weitere Gründe:

  • Daten zwischen Regionen migrieren
  • Daten zwischen Plattformen migrieren
  • Daten aus einer lokalen Datenbank zu Cloud SQL migrieren

Außerdem kann ein Replikat hochgestuft werden, wenn die ursprüngliche Instanz beschädigt wird.

Wenn es sich um eine Cloud SQL-Instanz handelt, werden die replizierte Instanz als primäre Instanz und die Kopien als Lesereplikate bezeichnet. Die primäre Instanz und die Lesereplikate befinden sich alle in Cloud SQL.

Wenn es sich um eine lokale Datenbank handelt, wird das Replikationsszenario als Replikat von einem externen Server bezeichnet. Dabei ist die replizierte Datenbank der Quelldatenbankserver. Die in Cloud SQL gespeicherten Kopien werden als Cloud SQL-Replikate bezeichnet. Außerdem gibt es eine Instanz, die den Quelldatenbankserver in Cloud SQL darstellt. Sie wird als Quelldarstellungsinstanz bezeichnet.

Sie können auch den Database Migration Service für die kontinuierliche Replikation von einem Quelldatenbankserver zu Cloud SQL verwenden.

Cloud SQL unterstützt die folgenden Replikattypen:

Lesereplikate

Lesereplikate werden verwendet, um Cloud SQL-Instanzen zu entlasten. Das Lesereplikat ist eine exakte Kopie der primären Instanz. Daten und andere Änderungen an der primären Instanz werden nahezu in Echtzeit auf dem Lesereplikat aktualisiert.

Lesereplikate gewähren nur Lesezugriff. Schreibvorgänge sind nicht möglich. Das Lesereplikat verarbeitet Abfragen, Leseanfragen und Analysetraffic. Dadurch wird die Last für die primäre Instanz reduziert. Es sind bis zu zehn Lesereplakte pro primäre Instanz möglich.

Verbindungen zu Replikaten werden direkt über deren Verbindungsnamen und IP-Adressen hergestellt. Wenn Sie eine Verbindung zu einem Replikat über eine private IP-Adresse herstellen, müssen Sie keine zusätzliche private VPC-Verbindung für das Replikat erstellen, da diese von der primären Instanz übernommen wird.

Weitere Informationen zum Erstellen eines Lesereplikats finden Sie unter Lesereplikate erstellen. Weitere Informationen zum Verwalten eines Lesereplikats finden Sie unter Lesereplikate verwalten.

Als Best Practice sollten Sie Lesereplikate in einer anderen Zone als die primäre Instanz platzieren, wenn Sie HA auf Ihrer primären Instanz verwenden. Dadurch wird sichergestellt, dass Lesereplikate weiter funktionieren, wenn die Zone mit der primären Instanz ausfällt. Weitere Informationen finden Sie unter Hochverfügbarkeit.

Regionenübergreifende Lesereplikate

Mit der regionenübergreifenden Replikation können Sie ein Lesereplikat in einer anderen Region als der primären Instanz erstellen. Sie erstellen ein regionsübergreifendes Lesereplikat genauso wie ein Replikat für eine einzige Region.

Regionenübergreifende Replikate:

  • verbessern die Leseleistung, da Replikate geografisch näher an Ihrer Anwendung verfügbar gemacht werden,
  • stellen eine zusätzliche Notfallwiederherstellungsfunktion bereit, damit Sie vor dem Ausfall einer ganzen Region geschützt sind und
  • ermöglichen die Datenmigration von einer Region in eine andere mit minimaler Ausfallzeit.

Weitere Informationen zu regionenübergreifenden Replikaten finden Sie unter Regionenübergreifende Replikate.

Externe Lesereplikate

Externe Lesereplikate sind externe MySQL-Instanzen, die von einer primären Cloud SQL-Instanz repliziert werden. Beispielsweise wird eine auf Compute Engine ausgeführte MySQL-Instanz als externe Instanz betrachtet.

Für externe Lesereplikate gelten die folgenden Einschränkungen:

  • Die Replikation auf eine von einer anderen Cloud-Plattform gehosteten MySQL-Instanz ist möglicherweise nicht möglich. Lesen Sie dazu die Dokumentation des Anbieters. Das Festlegen des Konfigurationsfelds replicate-ignore-db ist beispielsweise erforderlich. Cloud-Anbieter, bei denen dies nicht zulässig ist, werden nicht unterstützt. Weitere erforderliche Konfigurationsfelder finden Sie unter Externe Replikate konfigurieren.
  • Wenn die Replikation für wenige Stunden unterbrochen wird, z. B. durch einen Netzwerk- oder Serverausfall, fällt das Replikat hinter die primäre Instanz zurück. Das Replikat holt jedoch wieder auf, sobald eine neue Verbindung mit der primären Instanz hergestellt wird und die Replikation wieder startet. Wenn die Replikation jedoch länger unterbrochen wird als Cloud SQL-Replikations-Logs gespeichert werden (sieben Sicherungen), müssen Sie das Replikat löschen und ein neues erstellen.
  • Die Daten, die von der primären Instanz zum externen Replikat fließen, werden als ausgehender Netzwerktraffic in Rechnung gestellt. Die Preise für ausgehenden Netzwerktraffic Ihres Cloud SQL-Instanztyps finden Sie auf der Seite Preise.

Anwendungsfälle für Replikation

Für jeden Replikationstyp gelten die folgenden Anwendungsfälle:

Name Primär Replikat Vorteile und Anwendungsfälle Weitere Informationen
Lesereplikat Cloud SQL-Instanz Cloud SQL-Instanz
  • Zusätzliche Lesekapazität
  • Analyseziel
Regionenübergreifendes Lesereplikat Cloud SQL-Instanz Cloud SQL-Instanz
  • Zusätzliche Lesekapazität
  • Analyseziel
  • Zusätzliche Funktionen für die Notfallwiederherstellung
  • Leseleistung verbessern
  • Daten zwischen Regionen migrieren
Externes Lesereplikat Cloud SQL-Instanz MySQL-Instanz außerhalb von Cloud SQL
  • Geringere Latenzzeit externer Verbindungen
  • Analyseziel
  • Migrationspfad zu anderen Plattformen
Replikation von einem externen Server MySQL-Instanz außerhalb von Cloud SQL Cloud SQL for MySQL-Instanz
  • Migrationspfad zu Cloud SQL
  • Datenreplikation auf Google Cloud Platform
  • Analyseziel

Voraussetzungen für das Erstellen eines Lesereplikats

Bevor Sie ein Lesereplikat einer primären Cloud SQL-Instanz erstellen können, muss die Instanz die folgenden Anforderungen erfüllen:

  • Automatische Sicherungen müssen aktiviert sein.
  • Das Binärlogging muss aktiviert sein. Dazu ist erforderlich, dass die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert ist. Weitere Informationen zu den Auswirkungen dieser Logs
  • Nachdem das binäre Logging aktiviert wurde, muss mindestens eine Sicherung erstellt worden sein.

Zusätzliche Anforderungen für das externe Replikat:

  • Die MySQL-Version des Replikats muss mit der MySQL-Version der primären Instanz übereinstimmen oder höher sein. Weitere Informationen
  • Aus Sicherheitsgründen müssen Sie SSL auf Ihrer primären Instanz konfigurieren. Mehr erfahren

Auswirkungen der Aktivierung des binären Loggings

Damit Lesereplikate unterstützt werden, müssen Sie die Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren, damit auch das Binärlogging auf der primären Instanz aktiviert ist. Dies hat folgende Auswirkungen:

  • Leistungsaufwand

    Cloud SQL verwendet die zeilenbasierte Replikation mit den MySQL-Flags sync_binlog=1 und innodb_support_xa=true. Daher ist für jeden Schreibvorgang ein zusätzliches fsync-Laufwerk notwendig. Dies reduziert die Leistung.

  • Speicheraufwand

    Für die Speicherung von binären Logs wird der gleiche Preis wie für reguläre Daten berechnet. Binärlogs werden automatisch auf das Alter der ältesten automatischen Sicherung gekürzt. Cloud SQL bewahrt derzeit die letzten sieben automatischen und alle bei Bedarf durchgeführten Sicherungen auf. Die Größe der Binärlogs und die damit verbundenen Kosten hängen von der Arbeitslast ab. Schreiblastige Arbeitslasten verbrauchen beispielsweise mehr Speicherplatz für Binärlogs als leselastige Arbeitslasten.

    Mit dem MySQL-Befehl SHOW BINARY LOGS können Sie die Größe der Binärlogs anzeigen lassen.

    Wenn Sicherungen erstellt werden, werden die Logs zusammen mit den Daten in der Sicherung gespeichert.

  • Instanzneustart

    Wenn Sie die Binärprotokollierung aktivieren oder deaktivieren, wird die Instanz neu gestartet. Bestehende Datenbankverbindungen werden getrennt und müssen neu aufgebaut werden.

Binäres Logging in Lesereplikaten

  • Binäres Logging wird für Lesereplikatinstanzen unterstützt (nur MySQL 5.7 und 8.0). Sie aktivieren binäres Logging in einem Replikat mit denselben API-Befehlen wie auf der primären Instanz. Verwenden Sie dabei den Instanznamen des Replikats anstelle des Instanznamens 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.

    Binäres Logging kann auch dann für ein Replikat aktiviert werden, wenn die Sicherung auf der primären Instanz deaktiviert ist.

    Wenn ein Replikat mit diesem festgelegten Wert in einen eigenständigen Server umgewandelt wird, wird die Einstellung auf den sicheren Wert 1 auf dem eigenständigen Server zurückgesetzt.

Abrechnung

  • Für ein Lesereplikat wird derselbe Preis berechnet wie für eine Cloud SQL-Standardinstanz. Für die Datenreplikation entstehen keine Gebühren.
  • Da ein Replikat immer eine Verbindung zu seiner primären Instanz aufrechterhält, wird die primäre Instanz nie deaktiviert. Dieses Szenario könnte zu einer Preiserhöhung für die primäre Instanz führen. Weitere Informationen
  • Bei externen Replikaten werden die Daten, die von der primären Instanz zum externen Replikat fließen, als ausgehender Netzwerktraffic in Rechnung gestellt. Die Preise für ausgehenden Netzwerktraffic Ihres Cloud SQL-Instanztyps finden Sie auf der Seite Preise.
  • Neben den regulären Kosten für Cloud SQL-Instanzen fallen für ein regionsübergreifendes Replikat Gebühren für regionsübergreifenden ausgehenden Netzwerktraffic für Replikationslogs an, die von der primären Instanz an das Replikat gesendet werden (siehe Preise für ausgehenden Netzwerktraffic).
  • Die Preise für das regionenübergreifende Lesereplikat sind dieselben wie beim Erstellen einer neuen Instanz in der Region. Unter Cloud SQL-Instanzpreise können Sie sich weiter informieren und die geeignete Region auswählen.

Kurzreferenz für Cloud SQL-Lesereplikate

Thema Diskussion
Hochverfügbarkeit Lesereplikate unterstützen keine Hochverfügbarkeit.
Failover Eine primäre Instanz kann kein Failover auf ein Lesereplikat ausführen. Ebenso können Lesereplikate während eines Ausfalls keinen Failover ausführen.
Wartungsfenster Für Lesereplikate können keine Wartungsfenster festgelegt werden und sie teilen sich keine Wartungsfenster mit der primären Instanz. Ein Lesereplikat kann jederzeit gewartet werden. Lesereplikate werden zu anderen Zeiten gewartet als die primäre Instanz.
Upgrades mit Betriebsunterbrechung Upgrades können bei Lesereplikaten jederzeit Betriebsunterbrechungen verursachen.
Leistung Wenn Sie ein Lesereplikat erstellen, hat dies keine Auswirkungen auf die Leistung oder Verfügbarkeit der primären Instanz.
Mehrere Lesereplikate Sie können für jede primäre Instanz bis zu zehn Lesereplikate erstellen.
Load-Balancing Cloud SQL unterstützt kein Load-Balancing zwischen Replikaten. Verwenden Sie Verbindungs-Pooling und verteilen Sie Abfragen auf Replikate.
Einstellungen Die MySQL-Einstellungen der primären Instanz werden an das Replikat weitergegeben, einschließlich des Root-Passworts und Änderungen der Nutzertabelle. CPU- und Speicheränderungen werden nicht an das Replikat weitergegeben.
Parallele Replikation Weitere Informationen zur Verwendung der parallelen Replikation für Leistungsverbesserungen finden Sie unter Parallele Replikation konfigurieren.
Kerne und Arbeitsspeicher Für Lesereplikate kann eine andere Anzahl von Kernen und Arbeitsspeicher verwendet werden als für die primäre Instanz.
Nutzertabellen Sie können keine Änderungen an der Nutzertabelle auf dem Replikat vornehmen. Alle Nutzeränderungen müssen auf der primären Instanz durchgeführt werden.
Sicherungen Sie können keine Sicherungen auf dem Replikat konfigurieren.
Primäre Instanz wiederherstellen Sie können die primäre Instanz eines Replikats nicht wiederherstellen, solange das Replikat vorhanden ist. Sie müssen zuerst alle zugehörigen Replikate hochstufen oder löschen, bevor Sie eine Instanz aus einer Sicherung wiederherstellen oder darauf eine Wiederherstellung zu einem bestimmten Zeitpunkt machen.
Primäre Instanz löschen Bevor Sie eine primäre Instanz löschen können, müssen Sie alle zugehörigen Lesereplikate auf eigenständige Instanzen hochstufen oder die Lesereplikate löschen.
Binärlogging deaktivieren Bevor Sie Binärlogs für eine primäre Instanz deaktivieren können, müssen Sie alle ihre Lesereplikate hochstufen oder löschen.
Replikat eines Replikats erstellen Sie können kein Replikat eines Replikats erstellen.
Replikat anhalten Der Befehl stop ist bei Replikaten nicht verfügbar. Sie können restart, delete oder disable replication verwenden, aber Sie können sie nicht wie eine primäre Instanz anhalten.
Private IP-Adresse Wenn Sie eine Verbindung zu einem Replikat über eine private IP-Adresse herstellen, müssen Sie keine zusätzliche private VPC-Verbindung für das Replikat erstellen, da diese von der primären Instanz übernommen wird.

Nächste Schritte