Replikation

Auf dieser Seite wird beschrieben, wie Daten in Cloud Spanner repliziert werden, welche verschiedenen Typen von Cloud Spanner-Replikaten es gibt, welche Rollen sie bei Lese-/Schreibvorgängen spielen und was die Vorteile der Replikation sind.

Übersicht über Replikation in Cloud Spanner

Cloud Spanner erhält automatisch Replikationen auf Byte-Ebene von dem zugrunde liegenden verteilten Dateisystem, auf dem Spanner erstellt wurde (wie unter Lebensdauer von Lese- und Schreibvorgängen in Cloud Spanner beschrieben). Cloud Spanner schreibt Datenbankmutationen in Dateien dieses Dateisystems. Das Dateisystem übernimmt dann die Replikation und Wiederherstellung der Dateien, wenn ein Computer oder ein Laufwerk ausfällt.

Obwohl das zugrunde liegende verteilte Dateisystem, auf dem Cloud Spanner basiert, bereits Replikation auf Byte-Ebene bietet, repliziert auch Cloud Spanner Daten, um Ihnen die zusätzlichen Vorteile von Datenverfügbarkeit und geografischer Präsenz zu bieten. Auf übergeordneter Ebene sind alle Daten in Cloud Spanner in Zeilen organisiert. Cloud Spanner erstellt mehrere Kopien, sogenannte "Replikate", dieser Zeilen und speichert sie dann an verschiedenen geografischen Orten. Cloud Spanner verwendet ein synchrones, Paxos-basiertes Replikationsschema, bei dem abstimmende Replikate (ausführliche Erläuterung weiter unten) vor jeder Schreibanforderung eine Abstimmung vornehmen, bevor der Schreibvorgang festgeschrieben wird. Mit dieser weltweit synchronen Replikation können Sie die aktuellsten Daten aus allen nicht schreibgeschützten und schreibgeschützten Cloud Spanner-Replikaten auslesen.

Cloud Spanner erstellt Replikate jedes Datenbank-Splits, damit die oben genannten Konzepte mit der unter Schema und Datenmodell eingeführten Terminologie und den dort vorgestellten Konzepten verknüpft werden können. Ein Split stellt eine Reihe von zusammenhängenden Zeilen in einer übergeordneten Tabelle dar, wobei die Zeilen nach Primärschlüssel geordnet sind. Alle Daten eines Splits werden im Replikat zusammen gespeichert und Cloud Spanner stellt jedes Replikat aus einer unabhängigen Ausfallzone heraus bereit.

Ein Satz von Splits wird mithilfe von Paxos gespeichert und repliziert. In jedem Paxos-Replikatset wird eines der Replikate dazu bestimmt, als Leader zu fungieren. Leader-Replikate sind für das Verarbeiten von Schreibvorgängen verantwortlich. Eine Leseanforderung kann dagegen von jedem nicht schreibgeschützten oder schreibgeschützten Replikat verarbeitet werden, ohne dass dieses mit dem Leader kommunizieren muss. Falls jedoch ein starker Lesevorgang angefordert wird, wird der Leader üblicherweise herangezogen, um sicherzustellen, dass das schreibgeschützte Replikat alle aktuellen Mutationen empfangen hat. Weitere Informationen zu den Rollen, die Leader-Replikate und Replikate, die nicht als Leader fungieren, bei Lese- und Schreibvorgängen spielen, erhalten Sie weiter unten.

Vorteile der Cloud Spanner-Replikation

Wie bereits erwähnt, bietet die Cloud Spanner-Replikation folgende Vorteile:

  • Datenverfügbarkeit: Wenn Sie mehrere Kopien Ihrer Daten haben, sind diese für Clients, die die Daten auslesen möchten, besser verfügbar. Außerdem kann Cloud Spanner selbst dann Schreibvorgänge verarbeiten, wenn einige der Replikate nicht verfügbar sind. Es reicht nämlich aus, wenn eine Mehrheit der abstimmenden Replikate verfügbar ist, damit ein Schreibvorgang festgeschrieben werden kann.

  • Geografische Präsenz: Daten mit Cloud Spanner auf verschiedene Regionen und Kontinente verteilen zu können, bedeutet, dass Daten geografisch weniger weit von den benötigten Nutzern und Diensten entfernt sind und die Daten somit schneller zugänglich sind.

  • Einheitliche Datenbankerfahrung: Aufgrund der synchronen Replikation und der weltweit hohen Konsistenz verhält sich Cloud Spanner bei jedem Umfang gleich und ermöglicht so eine einheitliche Datenbankerfahrung.

  • Erleichterte Anwendungsentwicklung: Da in Cloud Spanner ACID-Transaktionen mit weltweit hoher Konsistenz möglich sind, ist es nicht erforderlich, dass Entwickler Anwendungen eine zusätzliche Logik für den Umgang mit "Eventual Consistency" beifügen. Dies beschleunigt und erleichtert die Anwendungsentwicklung und nachfolgende Wartung.

Replikattypen

Cloud Spanner verfügt über drei Replikattypen: Nicht schreibgeschützte Replikate, schreibgeschützte Replikate und Zeugenreplikate. Einzelregion-Instanzen verwenden ausschließlich nicht schreibgeschützte Replikate, während multiregionale Instanzkonfigurationen alle drei Typen kombiniert verwenden. (Eine ausführliche Erklärung hierfür finden Sie unter Warum gibt es schreibgeschützte Replikate und Zeugenreplikate? )

In der folgenden Tabelle sind die Typen der Cloud Spanner-Replikate und ihre Eigenschaften aufgelistet. In den folgenden Abschnitten werden die einzelnen Typen genauer beschrieben.

Replikattyp Kann abstimmen Kann Leader werden Kann Lesevorgänge verarbeiten
Nicht schreibgeschützt Ja Ja Ja
Schreibgeschützt Nein Nein Ja
Zeugen Ja Nein Nein

Nicht schreibgeschützt

Nicht schreibgeschützte Replikate unterstützen sowohl Lese-, als auch Schreibvorgänge. Diese Replikate besitzen folgende Eigenschaften:

  • Sie bewahren eine vollständige Kopie Ihrer Daten auf.
  • Sie verarbeiten Lesevorgänge.
  • Sie können abstimmen, ob ein Schreibvorgang festgeschrieben werden soll.
  • Sie wirken beim Bestimmen des Leaders mit.
  • Sie können als Leader fungieren.
  • Sie sind der einzige Typ, der in Einzelregion-Instanzen verwendet wird.

Schreibgeschützt

Schreibgeschützte Replikate unterstützen Lesevorgänge, aber keine Schreibvorgänge. Sie stimmen weder bei der Wahl des Leaders ab, noch darüber, ob Schreibvorgänge festgeschrieben werden sollen. Mithilfe schreibgeschützter Replikate können Sie somit Ihre Lesekapazität skalieren, ohne dass sich die Größe des Quorums erhöht, das für Schreibvorgänge erforderlich ist. Schreibgeschützte Replikate zeichnen sich durch Folgendes aus:

  • Sie werden nur von multiregionalen Instanzen verwendet.
  • Sie bewahren eine vollständige Kopie Ihrer Daten auf, die aus nicht schreibgeschützten Replikaten repliziert wurde.
  • Sie verarbeiten Lesevorgänge.
  • Sie stimmen nicht darüber ab, ob Schreibvorgänge festgeschrieben werden sollen. Daher besitzt der Speicherort der schreibgeschützten Replikate keinen Einfluss auf die Schreiblatenz.
  • Sie können in der Regel veraltete Lesevorgänge verarbeiten, ohne dass eine Umlaufkommunikation mit der standardmäßigen führenden Region erforderlich ist, vorausgesetzt, dass die Veralterung mindestens 15 Sekunden beträgt. Starke Lesevorgänge erfordern möglicherweise eine Umlaufkommunikation mit dem Leader-Replikat. Dieser Kommunikationsvorgang wird vom System automatisch ausgeführt. (Weitere Informationen zu veralteten und starken Lesevorgängen finden Sie weiter unten.)
  • Sie können nicht als Leader fungieren.

Zeugen

Zeugenreplikate unterstützen keine Lesevorgänge, stimmen jedoch darüber ab, ob Schreibvorgänge festgeschrieben werden. Sie erleichtern das Erreichen von Schreibquoren, ohne dass die Speicher- und Rechenressourcen benötigt werden, die nicht schreibgeschützte Replikate erfordern, um eine vollständige Kopie der Daten zu speichern und Lesevorgänge auszuführen. Zeugenreplikate zeichnen sich durch Folgendes aus:

  • Sie werden nur von multiregionalen Instanzen verwendet.
  • Sie bewahren keine vollständige Kopie Ihrer Daten auf.
  • Sie verarbeiten keine Lesevorgänge.
  • Sie stimmen darüber ab, ob Schreibvorgänge festgeschrieben werden sollen.
  • Sie wirken beim Bestimmen des Leaders mit, können aber selbst nicht als Leader fungieren.

Rollen der Replikate bei Schreib- und Lesevorgängen

In diesem Abschnitt werden die Rollen von Replikaten bei Cloud Spanner-Schreibvorgängen und -Lesevorgängen beschrieben. Dies ist hilfreich, um zu verstehen, warum Cloud Spanner in multiregionalen Konfigurationen schreibgeschützte Replikate und Zeugenreplikate verwendet.

Bei Schreibvorgängen

Client-Schreibanforderungen werden immer zuerst an das Leader-Replikat gesendet, selbst wenn sich ein Replikat, das nicht als Leader fungiert, näher am Client befindet oder das Leader-Replikat vom Client geografisch weit entfernt ist.

Das Leader-Replikat protokolliert den eingehenden Schreibvorgang und leitet ihn parallel an die Replikate weiter, die über diesen Schreibvorgang abstimmen dürfen. Jedes stimmberechtigte Replikat schließt seinen Schreibvorgang ab und teilt dem Leader dann mit, ob der Schreibvorgang festgeschrieben werden soll. Der Schreibvorgang wird festgeschrieben, wenn eine Mehrheit der abstimmenden Replikate (bzw. das "Schreibquorum") dafür stimmt, den Schreibvorgang festzuschreiben. Im Hintergrund protokollieren alle verbleibenden Replikate außer den Zeugenreplikaten den Schreibvorgang. Wenn ein nicht schreibgeschütztes oder ein schreibgeschütztes Replikat beim Protokollieren von Schreibvorgängen in Rückstand gerät, kann es die fehlenden Daten von einem anderen Replikat anfordern, damit es eine vollständige, aktuelle Kopie der Daten besitzt.

Bei Lesevorgängen

Für Client-Leseanforderungen wird möglicherweise das Leader-Replikat verwendet bzw. es muss mit diesem kommuniziert werden. Dies hängt vom Gleichzeitigkeitsmodus der Leseanforderung ab.

  • Lesevorgänge, die Teil einer Lese-Schreib-Transaktion sind, werden vom Leader-Replikat verarbeitet, da das Leader-Replikat die zum Erzwingen der Serialisierbarkeit erforderlichen Sperren beibehält.

  • Einzelne Leseaufrufe (ein Lesevorgang außerhalb des Kontexts einer Transaktion) und Lesevorgänge in schreibgeschützten Transaktionen erfordern möglicherweise eine Kommunikation mit dem Leader. Dies hängt vom Gleichzeitigkeitsmodus des Lesevorgangs ab. (Weitere Informationen zu diesen Gleichzeitigkeitsmodi erhalten Sie unter Lesetypen.)

    • Starke Leseanforderungen können an jedes nicht schreibgeschützte oder schreibgeschützte Replikat gesendet werden. Wenn die Anforderung an ein Replikat gesendet wird, das nicht als Leader fungiert, muss dieses mit dem Leader kommunizieren, um den Lesevorgang ausführen zu können.

    • Veraltete Leseanfragen werden an das am nächsten liegende, verfügbare Replikat mit oder ohne Schreibschutz weitergeleitet, welches so aktuell ist, wie der Zeitstempel der Anforderung es erfordert. Dies kann das Leader-Replikat sein, wenn sich kein anderes Replikat näher an dem Client befindet, der die Leseanfrage ausgegeben hat.