Informationen zur 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 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.

In einem Notfallwiederherstellungs-Szenario können Sie ein Replikat hochstufen, um es in eine primäre Instanz umzuwandeln. Auf diese Weise können Sie sie anstelle einer Instanz verwenden, die sich in einer Region befindet, in der es zu einem Ausfall gekommen ist. You can also promote a replica to replace an instance that's corrupted.

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.

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

Cloud SQL unterstützt keine Replikation zwischen zwei externen Servern. Cloud SQL unterstützt jedoch die auf die globale Transaktions-ID (GTID) gestützte Replikation. GTIDs identifizieren jede Transaktion auf dem Server und innerhalb einer Replikationseinrichtung eindeutig. Da jede Transaktion eine eindeutige ID hat, kann der MySQL-Server die ausgeführten Transaktionen verfolgen. Eine GTID verwendet absolute Koordinaten, sodass das Replikat einer Cloud SQL-Instanz auf seine primäre Instanz verweisen kann. Sie müssen keinen Dateinamen für das binäre Log oder eine Position in der Anweisung CHANGE MASTER angeben. Es gibt weniger Fehler bei Replikaten und bei der Wiederherstellung zu einem bestimmten Zeitpunkt. Aufgrund dieser Vorteile können Sie die GTID-basierte Replikation in Cloud SQL nicht deaktivieren.

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.

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.

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. Die folgenden Szenarien sind Anwendungsfälle für die Verwendung kaskadierender 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.
  • 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

  • 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.

Zum Planen der Konfiguration benötigen Sie eine Zielaktion für die Lesereplikate. In den nächsten beiden Abschnitten werden die Konfigurationen für die Notfallwiederherstellung und die Replikation in mehreren Regionen beschrieben.

Notfallwiederherstellung

Um zu verstehen, wie kaskadierende Replikate bei einem Ausfall zu einer schnellen Erholung beitragen können, sollten Sie das folgende Replikationsszenario betrachten:

Konfiguration

Darstellung einer kaskadierenden Replikatkonfiguration mit dem kaskadierenden Replikat in einer separaten Region

Ausfall

Darstellung der Werbung oder des Replikats während eines Ausfalls

Hochstufung

Die neue Instanz mit Replikaten

Wenn Sie eine Instanz in Region B in einer Konfiguration für die Notfallwiederherstellung verwenden möchten und Folgendes haben:

  • Replikate in derselben Region, die der primären Instanz zugeordnet ist (Replikat A)
  • Replikate in anderen Regionen (kaskadierendes Replikat), die mit dem primären Element verbunden sind.

Sie können Lesereplikate unter dem kaskadierenden Replikat in Region B erstellen.

Wenn auf dem Tab Ausfall ein Ausfall in Region A auftritt, wird das kaskadierende Replikat zu einer primären Instanz hochgestuft. Es befinden sich bereits Lesereplikate unter ihm, wodurch das RTO (Recovery Time Objective) reduziert wird.

Auf dem Tab Hochstufen sehen Sie, dass beim Hochstufen eines kaskadierenden Replikats unter diesem auch dessen Replikate hochgestuft und repliziert werden.

Replikation für mehrere Regionen

Another use case for cascading replicas is to distribute read capacity to a second region in a cost-efficient manner. Cascading replicas C and D can be created that replicate from Replica B. Clients can distribute read queries across replicas B, C, and D to reduce the load on each replica. The cost of cross-region network traffic is incurred only once, from the primary instance to Replica B. Die Replikation von B nach C und D verwendet die kostenlose Netzwerkübertragung innerhalb der Region.

Sie können eine Hierarchie von bis zu vier Instanzen mit kaskadierenden Replikaten für die Replikation über mehrere Regionen erstellen:

Primär A → Replikat B → Replikat C und Replikat D

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.

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 ausgehende Datenübertragung in Rechnung gestellt. Die Preise für die Datenübertragung für Ihren Cloud SQL-Instanztyp finden Sie auf der Seite Preise.

  • Wenn Sie ein externes Lesereplikat für eine Instanz erstellen und nur die Verwendung des Cloud SQL Auth-Proxys oder Cloud SQL Language Connectors für die Verbindung zu einer Instanz erzwingen, für die der Zugriff auf private Dienste konfiguriert ist, müssen Sie die Subnetzbereiche des Replikats den autorisierten Netzwerken der primären Instanz hinzufügen. Sie müssen alle Bereiche als autorisierte Netzwerke der Cloud SQL-Instanz konfigurieren.

    gcloud

    Wenn Sie die IP-Autorisierung für eine Instanz festlegen möchten, um Traffic aus IP-Adressbereichen eines externen Leserepliks zuzulassen, verwenden Sie den Befehl gcloud sql instances patch:

    gcloud sql instances patch \
--authorized-networks=IP_ADDRESS_RANGE_1/24,IP_ADDRESS_RANGE_2/24

    Ersetzen Sie IP_ADDRESS_RANGE_1 und IP_ADDRESS_RANGE_2 durch die IP-Adressbereiche Ihrer externen Lesereplika.

    REST

    Ersetzen Sie diese Werte in den folgenden Anfragedaten:

    • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
    • INSTANCE_NAME: Der Name Ihrer Cloud SQL-Instanz.
    • IP_ADDRESS_RANGE_1: der erste IP-Adressbereich Ihrer externen Lesereplik
    • IP_ADDRESS_RANGE_2: der zweite IP-Adressbereich Ihrer externen Lesereplik

    HTTP-Methode und URL:

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

    JSON-Text anfordern:

    {
  "kind": "sql#instance",
  "name": INSTANCE_NAME,
  "project": PROJECT_ID,
  "settings": {
    "ipConfiguration": {
      "authorizedNetworks": [{"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_1/24"}, {"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_2/24"}]},
  "kind": "sql#settings"
  }
}

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

    Sie sollten in etwa folgende JSON-Antwort erhalten:

    {
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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 in Google Cloud
  • 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är-Logging 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. Weitere Informationen

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

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 Namens der primären Instanz. Beachten Sie, dass die Begriffe enable binary logging und enable point-in-time recovery austauschbar sind.

    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.
  • Bei externen Replikaten werden die Daten, die von der primären Instanz zum externen Replikat fließen, als Datenübertragung abgerechnet. Die Preise für die Datenübertragung für Ihren Cloud SQL-Instanztyp finden Sie auf der Seite Preise.
  • 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.
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.
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.
Hochverfügbarkeit Mit Lesereplikaten können Sie Hochverfügbarkeit für die Replikate aktivieren.
Load-Balancing Cloud SQL unterstützt kein Load-Balancing zwischen Replikaten. Sie können Load-Balancing für Ihre Cloud SQL-Instanz implementieren. You can also use connection pooling to distribute queries across replicas with your load balancing setup for better performance.
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 Cloud SQL unterstützt kaskadierende Replikate. Sie können also bis zu zehn Replikate für eine einzelne primäre Instanz erstellen und Replikate dieser Replikate bis zu vier Ebenen verketten, einschließlich der primären.
Parallele Replikation Weitere Informationen zur Verwendung der parallelen Replikation für Leistungsverbesserungen finden Sie unter Parallele Replikation konfigurieren.
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 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.
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.
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.

Nächste Schritte