Replikation – Übersicht

Mit der Replikation in Cloud Bigtable können Sie die Verfügbarkeit und Langlebigkeit Ihrer Daten erhöhen. Dazu werden Ihre Daten in mehrere Regionen oder mehrere Zonen innerhalb derselben Region kopiert. Außerdem können Sie Arbeitslasten isolieren. Dazu leiten Sie verschiedene Arten von Anfragen an verschiedene Cluster weiter.

Auf dieser Seite lernen Sie die Funktionsweise der Replikation in Bigtable kennen sowie verschiedene gängige Anwendungsfälle. Außerdem werden das Konsistenzmodell, das Bigtable bei aktivierter Replikation verwendet, und die Vorgehensweise bei einem Failover von einem Cluster auf einen anderen erläutert.

Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen unter Übersicht über Bigtable vertraut machen.

Funktionsweise der Replikation

Zur Verwendung einer Replikation in einer Bigtable-Instanz, müssen Sie eine neue Instanz mit mehr als einem Cluster erstellen oder einer vorhandenen Instanz Cluster hinzufügen.

Bigtable unterstützt bis zu vier replizierte Cluster in Google Cloud-Zonen, in denen Bigtable verfügbar ist. Die Cluster einer Instanz müssen in eindeutigen Zonen angesiedelt sein. Sie können einen zusätzlichen Cluster in jeder Zone erstellen, in der Bigtable verfügbar ist. Durch die Platzierung von Clustern in unterschiedlichen Zonen oder Regionen können Sie auch dann noch auf Ihre Daten zugreifen, wenn eine der Google Cloud-Zonen oder -Regionen nicht verfügbar ist.

Wenn Sie eine Instanz mit mehr als einem Cluster erstellen, synchronisiert Bigtable sofort Ihre Daten zwischen den Clustern. Dabei wird in jeder Zone, in der Ihre Instanz über einen Cluster verfügt, eine separate, unabhängige Kopie der Daten erstellt. Wenn Sie einer vorhandenen Instanz einen neuen Cluster hinzufügen, kopiert Bigtable ebenso Ihre vorhandenen Daten aus der Zone des ursprünglichen Clusters in die Zone des neuen Clusters und synchronisiert dann Änderungen an Ihren Daten zwischen den Zonen.

Bigtable repliziert alle Änderungen an Ihren Daten automatisch. Dies schließt folgende Arten von Änderungen ein:

  • Aktualisierungen von Daten in vorhandenen Tabellen
  • Neue und gelöschte Tabellen
  • Hinzugefügte und entfernte Spaltenfamilien
  • Änderungen an der Speicherbereinigungsrichtlinie einer Spaltenfamilie

Bigtable behandelt jeden Cluster in der Instanz als primären Cluster, sodass Sie in jedem Cluster Lese- und Schreibvorgänge ausführen können. Außerdem lässt sich die Instanz so einrichten, dass Anfragen von verschiedenen Arten von Anwendungen an verschiedene Cluster weitergeleitet werden.

Bevor Sie Cluster in einer Instanz erstellen, sollten Sie sich mit den Einschränkungen vertraut machen, die beim Ändern von Richtlinien zur automatischen Speicherbereinigung für replizierte Tabellen gelten.

Anwendungsfälle

In diesem Abschnitt werden einige gängige Anwendungsfälle für die Bigtable-Replikation beschrieben. Unter Beispiele für Replikationseinstellungen finden Sie die besten Konfigurationseinstellungen für die einzelnen Anwendungsfälle sowie Implementierungstipps für andere Anwendungsfälle.

Anwendungsbereitstellung und Batchlesevorgänge isolieren

Wenn Sie einen einzelnen Cluster zum Ausführen eines Batchanalysejobs mit zahlreichen großen Lesevorgängen sowie zum Ausführen einer Anwendung verwenden, die sowohl Lese- als auch Schreibvorgänge verarbeitet, ist mit einer Verlangsamung der Vorgänge für den Nutzer zu rechnen. Wenn Sie hingegen die Replikation aktivieren, können Sie Anwendungsprofile mit Single-Cluster-Routing verwenden, um Batchanalysejobs und Anwendungstraffic an unterschiedliche Cluster weiterzuleiten. Die Nutzer Ihrer Anwendung sind somit nicht von den Batchjobs betroffen. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Verfügbarkeit verbessern

Wenn eine Instanz nur einen einzigen Cluster hat, sind die Langlebigkeit und Verfügbarkeit Ihrer Daten auf die Zone beschränkt, in der sich dieser Cluster befindet. Mit der Replikation kann sowohl die Langlebigkeit als auch die Verfügbarkeit verbessert werden, da separate Kopien Ihrer Daten in mehreren Zonen oder Regionen gespeichert und bei Bedarf automatisch per Failover zwischen Clustern übertragen werden. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Sicherungen praktisch in Echtzeit bereitstellen

In manchen Fällen müssen Anfragen immer an einen einzigen Cluster weitergeleitet werden, beispielsweise wenn das Lesen veralteter Daten inakzeptabel ist. Allerdings können Sie auch dann die Replikation verwenden. Dabei ist ein Cluster für die Verarbeitung von Anfragen zuständig, während ein anderer Cluster als echtzeitnahe Sicherung dient. Wenn der verarbeitende Cluster nicht mehr verfügbar ist, können Sie die Ausfallzeit durch ein manuelles Failover auf den Sicherungscluster minimieren. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Globale Präsenz für Ihre Daten gewährleisten

Sie können die Replikation an Standorten auf der ganzen Welt einrichten, um Ihre Daten näher an Ihre Kunden zu bringen. Sie können beispielsweise eine Instanz mit replizierten Clustern in den USA, Europa und Asien erstellen und Anwendungsprofile einrichten, um den Anwendungstraffic zum nächsten Cluster weiterzuleiten. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Konsistenzmodell

Für die Bigtable-Replikation gilt standardmäßig Eventual Consistency. Dieser Begriff bedeutet, dass eine Änderung, die in einen bestimmten Cluster geschrieben wurde, letztendlich auch in den anderen Clustern in der Instanz gelesen werden kann, allerdings erst, nachdem die Änderung zwischen den Clustern repliziert wurde.

Bei einer intakten Instanz kann sich bei der Replikation eine Verzögerung von ein paar Sekunden oder Minuten ergeben, allerdings nicht von Stunden. Wenn allerdings eine große Datenmenge in einen Cluster geschrieben wird oder ein Cluster überlastet bzw. vorübergehend nicht verfügbar ist, kann es eine Weile dauern, bis die Replikation nachgezogen hat. Die Replikation kann auch länger dauern, wenn die Cluster weit voneinander entfernt sind. Daher sollten Sie normalerweise nicht davon ausgehen, dass Sie immer den zuletzt geschriebenen Wert lesen oder dass eine Wartezeit von ein paar Sekunden nach einem Schreibvorgang für Bigtable ausreicht, um die Änderung zu replizieren.

Wenn Sie eine andere Konsistenzgarantie benötigen, kann Bigtable bei aktivierter Replikation auch Read-Your-Writes-Konsistenz bereitstellen. Diese gewährleistet, dass eine Anwendung nie Daten liest, die älter als die aktuellen Schreibvorgänge sind. Damit Read-Your-Writes-Konsistenz für eine Gruppe von Anwendungen gegeben ist, muss jede Anwendung in der Gruppe ein Anwendungsprofil mit konfiguriertem Single-Cluster-Routing verwenden. Außerdem müssen alle Anwendungsprofile Anfragen an denselben Cluster weiterleiten. Sie können die zusätzlichen Cluster der Instanz gleichzeitig für andere Zwecke verwenden.

Bei einigen Replikationsanwendungsfällen kann Bigtable auch strikte Konsistenz bieten. Diese sorgt dafür, dass alle Anwendungen die Daten im selben Zustand sehen. Damit strikte Konsistenz erreicht werden kann, müssen Sie die oben beschriebene Anwendungsprofil-Konfiguration mit Single-Cluster-Routing für Read-Your-Writes-Konsistenz verwenden. Dabei dürfen Sie jedoch nicht die zusätzlichen Cluster der Instanz verwenden, es sei denn, es muss ein Failover zu einem anderen Cluster erfolgen. Anhand der Beispiele für Replikationseinstellungen können Sie feststellen, ob dies für Ihren Anwendungsfall möglich ist.

Konfliktlösung

Jeder Zellenwert in einer Bigtable-Tabelle wird durch das Vierertupel (Zeilenschlüssel, Spaltenfamilie, Spaltenqualifizierer, Zeitstempel) eindeutig identifiziert. In dem seltenen Fall, dass zwei Schreibvorgänge mit demselben identischen Vierertupel an zwei verschiedene Cluster gesendet werden, löst Bigtable den Konflikt automatisch mithilfe eines internen Algorithmus zum letzten Schreibvorgang auf Grundlage der serverseitigen Zeit auf. Die Bigtable-Implementierung "Last write Wins" (Zeitpunkte des letzten Schreibvorgangs) ist deterministisch. Wenn die Replikation aufholt, haben alle Cluster denselben Wert für das Vierertupel.

Anwendungsprofile

Wenn eine Instanz Replikation verwendet, geben Sie mithilfe von Anwendungsprofilen (bzw. App-Profilen) Routingrichtlinien an. Anwendungsprofile bestimmen außerdem, ob Sie Transaktionen für einzelne Zeilen ausführen können. Dazu gehören Read-Modify-Write-Vorgänge (einschließlich Erhöhungen und Anfügungen) sowie Check-Mutate-Vorgänge (auch bedingte Mutationen oder bedingte Schreibvorgänge genannt).

Weitere Informationen finden Sie unter Anwendungsprofile. Beispiele für Einstellungen, die Sie zum Implementieren gängiger Anwendungsfälle verwenden können, finden Sie unter Beispiele für Replikationseinstellungen.

Routingrichtlinien

Jedes Anwendungsprofil hat eine Routingrichtlinie, die steuert, welche Cluster eingehende Anfragen von Ihren Anwendungen verarbeiten. Zu den Optionen für Routingrichtlinien gehören:

  • Single-Cluster-Routing: Sendet alle Anfragen an einen von Ihnen angegebenen Cluster.
  • Multi-Cluster-Routing an einen beliebigen Cluster: Sendet Anfragen an den nächsten verfügbaren Cluster in der Instanz.
  • Clustergruppen-Routing: Sendet Anfragen an den nächsten verfügbaren Cluster innerhalb einer Clustergruppe, die Sie in den Anwendungsprofileinstellungen angeben.

Failovers

Wenn ein Cloud Bigtable-Cluster nicht mehr reagiert, ermöglicht dessen Replikation die Weiterleitung des eingehenden Traffics per Failover an einen anderen Cluster derselben Instanz. Failovers können manuell oder automatisch ausgelöst werden, je nachdem, welches Anwendungsprofil eine Anwendung verwendet und wie das Anwendungsprofil konfiguriert ist.

Weitere Informationen finden Sie unter Failovers.

Zeilenbereiche bei aktivierter Replikation löschen

Mit der Bigtable Admin API können Sie einen zusammenhängenden Zeilenbereich aus einer Tabelle auf Basis der zugehörigen Zeilenschlüssel löschen. Bei Instanzen ohne Replikation kann Bigtable einen Zeilenbereich schnell und effizient löschen. Allerdings ist das Löschen eines Zeilenbereichs bei aktivierter Replikation wesentlich zeitaufwendiger und ineffizienter.

Nächste Schritte