Informationen zur Replikation in Cloud SQL

Durch Replikation können Kopien einer Cloud SQL-Instanz 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 für die Replikation sind die Migration von Daten zwischen Regionen.

Wenn eine ursprüngliche Instanz beschädigt ist, kann ein Replikat außerdem zu einer eigenständigen Instanz hochgestuft werden. In diesem Fall wird diese Instanz von vorhandenen Replikaten nicht als primäre Instanz betrachtet.

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 das erste Replikat erstellt wird:

  • Für die primäre Instanz wird das vollständige Wiederherstellungsmodell für alle Datenbanken festgelegt, die sich derzeit auf der primären Instanz befinden.

  • Ein temporäres Laufwerk wird erstellt und eine vollständige Sicherung wird erstellt und auf dem temporären Laufwerk gespeichert. Das temporäre Laufwerk wird nach Abschluss der Replikaterstellung gelöscht.

Wenn der Nutzer während der ersten Replikaterstellung zum einfachen Wiederherstellungsmodell wechselt, schlägt die Replikaterstellung fehl.

Folgendes gilt für Datenbanken, die der primären Instanz nach dem Erstellen der Replikate hinzugefügt werden:

  • Die Datenbanken werden den Verfügbarkeitsgruppen automatisch hinzugefügt und anhand von automatisches Seeding in den Replikaten ausgefüllt.
  • Jede Erstellung eines Replikats ruft eine vollständige Sicherung (vollständiges Wiederherstellungsmodell) von Datenbanken auf der primären Instanz auf. Nach dem Replikat erstellte Anmeldungen und Serverobjekte werden nicht repliziert.

Cloud SQL unterstützt die folgenden Replikattypen:

Cloud SQL unterstützt keine Replikation zwischen zwei externen Servern.

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 8 Lesereplikate 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 die Verbindung 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.

Geeigneten Maschinentyp auswählen

Lesereplikate können einen anderen Maschinentyp haben als der primäre Server. Sie sollten Messwerte auf Ihrer Instanz überwachen, z. B. die CPU- und Arbeitsspeichernutzung, damit die Replikatinstanz für ihre Arbeitslast korrekt dimensioniert wird, insbesondere wenn sie kleiner als die primäre Instanz ist. Eine Replikatinstanz mit geringer Größe ist anfälliger für eine schlechte Leistung, z. B. häufige OOM-Ereignisse (Out-of-Memory).

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.

Bei SQL Server-Lesereplikaten wird davon ausgegangen, dass sich das Replikat im selben virtuellen Netzwerk wie das primäre Replikat befindet oder dass die Replikate über öffentliche IP-Adressen kommunizieren.

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.

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

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
  • Leseleistung verbessern
  • Aus Replikaten exportieren
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
SQL Server-Replikation Instanz außerhalb von Cloud SQL Cloud SQL for SQL Server-Instanz
  • Migrationspfad zu Cloud SQL
  • Replikation von einem externen Server zu Cloud SQL
  • Replikation von Cloud SQL auf einen externen Server
  • Replikation zwischen Cloud SQL-Instanzen
  • Datenreplikation auf die Google Cloud Platform
  • Analyseziel

Abrechnung

  • Für ein Lesereplikat wird derselbe Preis berechnet wie für eine Cloud SQL-Standardinstanz. Für die Datenreplikation entstehen keine Gebühren.
  • Die Preise für das regionenübergreifende Lesereplikat sind dieselben wie beim Erstellen einer neuen Cloud SQL Instanz in der Region. Unter Cloud SQL-Instanzpreise können Sie sich weiter informieren und die geeignete Region auswählen. Neben den regulären Kosten für die Instanz fallen für ein regionenübergreifendes Replikat Gebühren für regionenübergreifende Datenübertragung für Replikationslogs an, die von der primären Instanz an die Replikatinstanz gesendet werden, wie unter Preise für ausgehenden Netzwerktraffic beschrieben.

Kurzreferenz für Cloud SQL-Lesereplikate

Thema Diskussion
Sicherungen Sie können keine Sicherungen auf dem Replikat konfigurieren.
Kerne und Arbeitsspeicher Für Lesereplikate kann eine andere Anzahl von Kernen und Arbeitsspeicher verwendet werden als für die primäre Instanz.
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.
Replikat löschen Wenn Sie ein Replikat löschen, hat dies keine Auswirkungen auf den Status der primären Instanz.
Replizierte Datenbank löschen Sie können eine replizierte SQL Server-Datenbank mithilfe der Google Cloud Console oder des gcloud-Befehls löschen. Der Löschvorgang wird automatisch an die Replikate weitergegeben. Sie können eine replizierte SQL Server-Datenbank nicht mit T-SQL-Befehlen löschen.
Failover Eine primäre Instanz kann nur dann ein Failover auf ein Replikat ausführen, wenn das Replikat ein DR-Replikat ist. Lesereplikate können während eines Ausfalls keinen Failover ausführen.
Load Balancing Cloud SQL unterstützt kein Load-Balancing zwischen Replikaten.
Wartungsfenster Sie können keine Wartungsfenster für ein Lesereplikat konfigurieren. Lesereplikate teilen sich jedoch Wartungsfenster mit der primären Instanz. Während der Wartung aktualisiert Cloud SQL zuerst alle Lesereplikate, bevor die primäre Instanz aktualisiert wird.
Mehrere Lesereplikate Sie können für jede primäre Instanz bis zu acht Lesereplikate erstellen.
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.
Primäre Instanz wiederherstellen Sie können die primäre Instanz eines Replikats nicht wiederherstellen, solange das Replikat vorhanden ist. Bevor Sie eine Instanz aus einer Sicherung wiederherstellen oder darauf eine Wiederherstellung zu einem bestimmten Zeitpunkt durchführen, müssen Sie alle zugehörigen Replikate hochstufen oder löschen.
Einstellungen Die Einstellungen der primären Instanz werden an das Replikat weitergegeben, einschließlich Änderungen an den Daten zu Nutzern, die auf die Instanz zugreifen können.
Replikat anhalten Der Befehl stop ist bei Replikaten nicht verfügbar. Sie können restart oder delete verwenden, aber Sie können sie nicht wie eine primäre Instanz anhalten.
Replikatupgrade Upgrades können bei Lesereplikaten jederzeit Betriebsunterbrechungen verursachen.
Nutzertabellen Sie können keine Änderungen am Replikat vornehmen. Alle Nutzeränderungen müssen auf der primären Instanz durchgeführt werden.

Beschränkungen

  • Dieses Feature gilt nur für die folgenden Versionen von Cloud SQL for SQL Server:

    • SQL Server 2017 Enterprise
    • SQL Server 2019 Enterprise
    • SQL Server 2022 Enterprise

  • Anmeldungen werden nicht an ein Replikat weitergegeben.

  • Sie müssen das Replikat mit T-SQL und/oder SQL Server Management Studio überwachen.

  • Bevor Sie eine Datenbank löschen, müssen Sie Ihre Datenbankverbindungen schließen.

  • Wenn Sie ein Replikat erstellen, darf die primäre Instanz keine Datenbanken im Einzelnutzermodus enthalten. Andernfalls schlägt die Replikaterstellung fehl.

Nächste Schritte