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 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:

Mit der Erzwung von Verbindungen können Sie festlegen, dass nur der Cloud SQL Auth-Proxy oder Cloud SQL Language Connectors für die Verbindung zu Cloud SQL-Instanzen verwendet werden dürfen. Bei der Connector-Erzwingung werden direkte Verbindungen zur Datenbank von Cloud SQL abgelehnt. Sie können keine Lesereplikate für eine Instanz erstellen, für die die Connector-Erzwigung aktiviert ist. Wenn eine Instanz Lesereplikate hat, können Sie die Connector-Erzwigung für die Instanz nicht aktivieren.

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.

Kaskadierende Lesereplikate

Mit der kaskadierenden Replikation können Sie ein Lesereplikat unter einem anderen Lesereplikat in derselben oder einer anderen Region erstellen. Kaskadenrepliken werden mithilfe von verteilten Verfügbarkeitsgruppen implementiert. Beispiele für Anwendungsfälle für kaskadierende Replikate:

  • Notfallwiederherstellung: Sie können eine kaskadierende Hierarchie von Lesereplikaten verwenden, um die Topologie Ihrer primären Instanz und der zugehörigen Lesereplikate zu simulieren. Während eines Ausfalls wird das ausgewählte Lesereplikat zur primären Instanz hochgestuft. Die Lesereplikate unter der neuen primären Instanz werden weiterhin repliziert und sind einsatzbereit. Die alte primäre Instanz wird zu einem sekundären Replikat der neuen primären Instanz, sobald sie verfügbar ist. Sie können nach der Wiederherstellung mit einem Umschalten wieder zur alten primären Instanz wechseln. Weitere Informationen zur Verwendung kaskadierter Replikate für die Notfallwiederherstellung finden Sie unter Notfallwiederherstellung.
  • Leistungsverbesserungen: Um die Belastung der primären Instanz zu reduzieren, können Sie die Replikationsarbeit auf mehrere Lesereplikate verteilen.
  • Lesevorgänge skalieren: Sie können weitere Replikate haben, um die Leselast zu teilen.
  • Kostenreduzierung: Sie können Netzwerkkosten reduzieren, indem Sie ein einzelnes kaskadierendes Replikat mit regionenübergreifender Replikation in anderen Regionen verwenden.

Terminologie

  • Kaskadierbares Replikat: Ein regionenübergreifendes Lesereplikat, das für Switchover- und Replikations-Failover-Vorgänge bei der erweiterten Notfallwiederherstellung (DR) mit Cloud SQL for SQL Server verwendet werden kann.
  • Kaskadierendes Replikat: Ein Lesereplikat, das ein eigenes Replikat haben kann.
  • Ebenen: Sie können Ebenen von Replikaten in einer kaskadierenden Replikathierarchie erstellen. Beispiel: Wenn Sie einer Instanz vier Replikate hinzufügen, befinden sich diese vier Replikate auf derselben Ebene.
  • Gleichgeordnete Instanzen: Mehrere Replikate, die aus derselben primären Instanz repliziert wurden. Gleichgeordnete Elemente befinden sich in der Replikathierarchie auf derselben Ebene. Ein Replikat kann offiziell bis zu acht gleichgeordnete Elemente haben.
  • Leaf replica: A read replica that does not have any replicas of its own. In einer mehrstufigen Replikationshierarchie ist das Blatt-Replikat die letzte Ebene.
  • Hochstufen: Eine Aktion, bei der ein Replikat auf einer beliebigen Hierarchieebene in eine primäre Instanz umgewandelt wird. Beim Hochstufen wird die kaskadierende Replikathierarchie beibehalten.

Kaskadierende Replikate konfigurieren

Mit kaskadierenden Replikaten können Sie Lesereplikate vorhandenen Replikaten hinzufügen. Sie können bis zu vier Replikatebenen hinzufügen, einschließlich der primären Instanz. Wenn Sie das oberste Replikat einer kaskadierende Hierarchie hochstufen, wird es zu einer primären Instanz, deren kaskadierenden Replikate weiterhin repliziert werden.

Weitere Informationen zum Konfigurieren verteilter Verfügbarkeitsgruppen finden Sie unter Verteilte Always On-Verfügbarkeitsgruppe konfigurieren.

Beschränkungen

  • Sie können kein Replikat löschen, unter dem Replikate existieren. Um ein solches Replikat zu löschen, müssen Sie mit den Blattreplikaten beginnen und sich durch die Hierarchie nach oben arbeiten.
  • Die Abhängigkeit von Zirkelregionen wird nicht unterstützt. Damit das kaskadierende Replikat in derselben Region wie die primäre Instanz vorhanden ist, muss sich auch das kaskadierende Replikat in dieser Region befinden.
  • Sie müssen kaskadierbare Replikate in einer anderen Region als der Region der primären Instanz erstellen. Anschließend können Sie kaskadierende Replikate in derselben Region wie das kaskadierbare Replikat erstellen.

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 in Google Cloud
  • 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 Lesereplikate teilen sich Wartungsfenster mit der primären Instanz. Die Replikate folgen den Wartungseinstellungen für die primäre Instanz, einschließlich Wartungsfenster, Neuplanung und Wartungsausschlusszeitraum. 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