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 Cloud Bigtable kennen sowie verschiedene gängige Anwendungsfälle. Außerdem werden das Konsistenzmodell, das Cloud Bigtable bei aktivierter Replikation verwendet, und die Vorgehensweise bei einem Failover von einem Cluster auf einen anderen erläutert.

Voraussetzung dafür ist die Kenntnis der Übersicht über Cloud Bigtable.

Funktionsweise der Replikation

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

Cloud Bigtable unterstützt bis zu vier replizierte Cluster in Google Cloud-Zonen, in denen Cloud Bigtable verfügbar ist. Die Cluster einer Instanz müssen jeweils in eindeutigen Zonen angesiedelt sein. Sie können in jeder Zone, in der Cloud Bigtable verfügbar ist, einen zusätzlichen Cluster erstellen. 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 Cloud 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 Cloud 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.

Cloud 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

Cloud 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 Cloud 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 Cloud Bigtable-Replikation gilt standardmäßig Eventual Consistency. Dieser Begriff bedeutet, dass eine Änderung, die in einen bestimmten Cluster geschrieben wurde, letztendlich auch auf den anderen Clustern in der Instanz wieder gelesen werden kann, allerdings erst, nachdem die Änderung zwischen den Clustern repliziert wurde.

Wenn Ihre Instanz reagiert, beträgt die Verzögerung der Replikation in der Regel nur wenige Sekunden oder Minuten, nicht 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 Cloud Bigtable ausreicht, um die Änderung zu replizieren.

Wenn Sie eine andere Konsistenzgarantie benötigen, kann Cloud 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 Cloud 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.

Anwendungsprofile

Wenn eine Instanz Replikation verwendet, steuern Sie mit Anwendungsprofilen (oder kurz App-Profilen), welche Cluster die von Anwendungen eingehenden Anfragen verarbeiten. 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.

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