Replikation

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

Überblick

Spanner repliziert automatisch auf Byteebene. Wie in Lebensdauer von Spanner-Lese- und -Schreibvorgängen beschrieben, nutzt es diese Funktion im zugrunde liegenden Dateisystem, auf dem sie basiert. Spanner schreibt Datenbankmutationen in Dateien in diesem Dateisystem. Das Dateisystem übernimmt die Replizierung und Wiederherstellung der Dateien, wenn ein Computer oder ein Laufwerk ausfällt.

Obwohl das zugrunde liegende verteilte Dateisystem, auf dem Spanner basiert, bereits Replikation auf Byteebene bietet, repliziert Spanner auch Daten, um die zusätzlichen Vorteile der Datenverfügbarkeit und geografischen Lokalität bereitzustellen. Auf übergeordneter Ebene sind alle Daten in Spanner in Zeilen organisiert. Spanner erstellt mehrere Kopien oder „Replikate“ dieser Zeilen und speichert diese Replikate dann in verschiedenen geografischen Gebieten. Spanner verwendet ein synchrones, Paxos-basiertes Replikationsschema, bei dem abstimmende Replikate bei jeder Schreibanfrage eine Abstimmung vornehmen, bevor der Schreibvorgang festgeschrieben wird. Dieses Attribut der global synchronen Replikation gibt Ihnen die Möglichkeit, die aktuellsten Daten aus jedem nicht schreibgeschützten oder schreibgeschützten Spanner-Replikat zu lesen.

Spanner erstellt Replikate jedes Datenbank-Splits. Ein Split enthält einen Bereich zusammenhängender Zeilen, wobei die Zeilen nach Primärschlüssel geordnet sind. Alle Daten in einem Split werden zusammen im Replikat gespeichert und Spanner stellt jedes Replikat aus einer unabhängigen Fehlerzone bereit. Weitere Informationen finden Sie unter Informationen zu Schemas.

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.

Vorteile der Spanner-Replikation

Zu den Vorteilen der Spanner-Replikation gehören:

• 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 Spanner auch dann Schreibvorgänge bereitstellen, wenn einige der Replikate nicht verfügbar sind, da nur die Mehrheit der abstimmenden Replikate erforderlich ist, um einen Schreibvorgang festschreiben zu können.

• Geografische Lokalität: Die Möglichkeit, Daten mit Spanner auf verschiedene Regionen und Kontinente zu platzieren, bedeutet, dass Daten geografisch näher an den Nutzern und Diensten, die sie benötigen, und somit schneller zugänglich sind.

• Einheitliche Datenbankerfahrung: Dank seiner synchronen Replikation und globaler strikter Konsistenz bietet Spanner eine einzige Datenbankerfahrung.

• Einfachere Anwendungsentwicklung: Da Spanner ACID-konform ist und weltweit hohe Konsistenz bietet, müssen Entwickler, die mit Spanner arbeiten, keine zusätzliche Logik für den Umgang mit Eventual Consistency hinzufügen. Dadurch werden Anwendungsentwicklung und nachfolgende Wartung schneller und einfacher.

Replikattypen

Spanner verfügt über drei Replikattypen: nicht schreibgeschützte Replikate, schreibgeschützte Replikate und Zeugenreplikaten. Die Regionen und Replikationstopologien, die grundlegende Instanzkonfigurationen bilden, sind festgelegt. Regionale Basisinstanzkonfigurationen verwenden nur nicht schreibgeschützte Replikate. Basiskonfigurationen mit zwei Regionen verwenden nicht schreibgeschützte Replikate und Zeugenreplikaten, während multiregionale Basisinstanzen eine Kombination aus allen drei Replikattypen verwenden. Sie können benutzerdefinierte Instanzkonfigurationen erstellen und zusätzliche schreibgeschützte Replikate für regionale und multiregionale Instanzkonfigurationen hinzufügen.

In der folgenden Tabelle sind die Typen der Spanner-Replikate und ihre Attribute zusammengefasst:

Replikattyp	Kann abstimmen	Kann Leader werden	Kann Lesevorgänge verarbeiten	Kann das Replikat manuell konfigurieren
Nicht schreibgeschützt	Ja	Ja	Ja	no
Schreibgeschützt	Nein	Nein	yes	ja^*
Zeugen	yes	Nein	Nein	no

^* Weitere Informationen finden Sie unter Instanz mit einer benutzerdefinierten Instanzkonfiguration erstellen.

Nicht schreibgeschützte Replikate

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ützte Replikate

Schreibgeschützte Replikate unterstützen nur Lesevorgänge, aber keine Schreibvorgänge. Diese Replikate stimmen weder für Leaders ab noch für das Commit von Schreibvorgängen. Sie ermöglichen es Ihnen also, Ihre Lesekapazität zu skalieren, ohne das Quorum, das für Schreibvorgänge erforderlich ist, zu erhöhen. Schreibgeschützte Replikate zeichnen sich durch Folgendes aus:

• Sie bewahren eine vollständige Kopie Ihrer Daten auf, die aus nicht schreibgeschützten Replikaten repliziert wird.
• Sie verarbeiten Lesevorgänge.
• Nehmen Sie nicht an der Abstimmung teil, um Schreibvorgänge zu festigen. Daher besitzt der Speicherort der schreibgeschützten Replikate keinen Einfluss auf die Schreiblatenz.

• Wenn es sich um das nächste Replikat zu Ihrer Anwendung handelt, kann das schreibgeschützte Replikat normalerweise veraltete Lesevorgänge verarbeiten, ohne dass ein Umlauf in die standardmäßige führende Region erforderlich ist, vorausgesetzt, die Veralterung beträgt mindestens 15 Sekunden. Sie können auch gerichtete Lesevorgänge verwenden, um schreibgeschützte Transaktionen und einzelne Lesevorgänge an einen bestimmten Replikattyp oder eine bestimmte Region in einer multiregionalen Instanzkonfiguration weiterzuleiten. Weitere Informationen finden Sie unter Richte Lesevorgänge.

  Starke Lesevorgänge erfordern möglicherweise einen Umlauf zum Leader-Replikat. Der Umlauf dient nur zum Aushandeln des Zeitstempels und nicht zum Versenden der tatsächlichen Daten vom Leader. Die Zeitstempelaushandlung ist ein CPU-effizienter Vorgang am Leader. In der Regel sind die Daten bereits unterwegs. Diese Kommunikation wird vom System automatisch abgewickelt.

  Weitere Informationen zu veralteten und starken Lesevorgängen finden Sie im Abschnitt „In Lesevorgängen“.

• Sie können nicht als Leader fungieren.

Sie können eine benutzerdefinierte regionale oder multiregionale Instanzkonfiguration erstellen und optionale schreibgeschützte Replikate hinzufügen, um Lesevorgänge zu skalieren und veraltete Lesevorgänge mit niedriger Latenz zu unterstützen. Sie können unter Optionale Region aufgeführte Standorte als optionales schreibgeschütztes Replikat hinzufügen. Wenn der ausgewählte schreibgeschützte Replikatstandort nicht angezeigt wird, können Sie eine neue optionale schreibgeschützte Replikatregion anfordern. Beachten Sie, dass Sie die Replikationstopologie von Basisinstanzkonfigurationen, die fest sind, nicht ändern können.

Für alle optionalen schreibgeschützten Replikate fallen Kosten für Computing-Kapazität und Speicher an. Die Spanner-SLAs der Instanzkonfiguration werden durch das Hinzufügen schreibgeschützter Replikate zu einer benutzerdefinierten Instanzkonfiguration nicht geändert. Wenn Sie einem Kontinent ein schreibgeschütztes Replikat hinzufügen möchten, der sich auf einem anderen Kontinent als die führende Region befindet, empfehlen wir, mindestens zwei schreibgeschützte Replikate hinzuzufügen. Dadurch wird eine niedrige Leselatenz beibehalten, falls eines der schreibgeschützten Replikate ausfällt.

Wenn Sie schreibgeschützte Replikate hinzufügen, ist die Replikationslast beim Leader-Replikat höher, was sich auf die Leistung auswirken kann. Testen Sie als Best Practice zuerst Leistungsarbeitslasten in Nicht-Produktionsinstanzen in der benutzerdefinierten Instanzkonfiguration. Im Dashboard für die Interregionale Latenz und Durchsatz-Benchmark finden Sie die Mediandaten zur interregionalen Latenz. Wenn Sie beispielsweise eine benutzerdefinierte Instanzkonfiguration mit der multiregionalen Basiskonfiguration eur6 und einem optionalen schreibgeschützten Replikat in us-east1 erstellen, beträgt die erwartete hohe Leselatenz für einen Client in us-east1 aufgrund der Umlaufzeit zur führenden Region in europe-west4 etwa 100 Millisekunden. Veraltete Lesevorgänge mit ausreichender Veralterung verursachen keinen Umlauf und sind daher viel schneller. Sie können auch den Messwert Latenz nach Transaktionstyp verwenden, um Latenzdaten für Transaktionen vom Typ Lese-Schreib- und schreibgeschützte Transaktionen aufzurufen.

Eine Anleitung finden Sie unter Benutzerdefinierte Instanzkonfiguration erstellen.

Zeugenreplikate

Zeugenreplikate unterstützen keine Lesevorgänge, stimmen aber 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 der Daten auf.
• Stellen Sie keine Lesevorgänge bereit.
• 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.

Die Rolle von Replikaten bei Schreib- und Lesevorgängen

In diesem Abschnitt wird die Rolle von Replikaten bei Schreib- und Lesevorgängen in Spanner beschrieben. Damit wird deutlich, warum Spanner Zeugenreplikate in multiregionalen Konfigurationen verwendet.

Bei Schreibvorgängen

Client-Schreibanfragen werden immer zuerst auf dem Leader-Replikat verarbeitet, auch wenn sich ein Nicht-Leader-Replikat näher am Client befindet oder das Leader-Replikat geografisch vom Client entfernt ist. Wenn Sie eine multiregionale Instanzkonfiguration verwenden und sich Ihre Clientanwendung in einer nicht führenden Region befindet, verwendet Spanner ein Leader-spezifisches Routing, um Lese-Schreib-Transaktionen dynamisch weiterzuleiten, um die Latenz in Ihrer Datenbank zu reduzieren. Weitere Informationen finden Sie unter Leader-aware-Routing.

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. erfordert eine Kommunikation mit diesem. 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 nächstgelegene verfügbare Replikat mit oder ohne Lese-/Schreibzugriff geleitet, das dem Zeitstempel der Anfrage am nächsten ist. Dies kann das Leader-Replikat sein, wenn es dem Client, der die Leseanfrage ausgestellt hat, am nächsten ist.

Zusatz: Warum gibt es schreibgeschützte Replikate und Zeugenreplikate?

Multiregionale Basiskonfigurationen verwenden eine Kombination aus nicht schreibgeschützten, schreibgeschützten und Zeugenreplikaten, während Basiskonfigurationen mit zwei Regionen Lese-/Schreib- und Zeugenreplikate verwenden, während regionale Basiskonfigurationen nur nicht schreibgeschützte Replikate verwenden. Die Gründe für diesen Unterschied hängen mit den unterschiedlichen Rollen von Replikaten bei Schreib- und Lesevorgängen zusammen. Bei Schreibvorgängen benötigt Spanner, dass die Mehrheit der abstimmenden Replikate einem Commit zustimmen muss, damit eine Mutation festgeschrieben werden kann. Mit anderen Worten, jeder Schreibvorgang in eine Spanner-Datenbank erfordert eine Kommunikation zwischen votierenden Replikaten. Es empfiehlt sich, die geringstmögliche Anzahl abstimmender Replikate zu verwenden und diese so nah beieinander wie möglich zu platzieren, um die Latenz dieser Kommunikationsvorgänge zu minimieren. Daher enthalten regionale Basiskonfigurationen genau drei nicht schreibgeschützte Replikate, von denen sich jedes in einer eigenen Verfügbarkeitszone befindet, eine vollständige Kopie Ihrer Daten enthält und abgestimmt werden kann. Wenn ein Replikat fehlschlägt, können die anderen beiden trotzdem ein Schreibquorum bilden. Da sich die Replikate in dieser Konfiguration in derselben geografischen Region befinden, sind die Netzwerklatenzen minimal.

Multiregionale Basiskonfigurationen enthalten standardmäßig mehr Replikate. Diese Replikate befinden sich in verschiedenen Rechenzentren, sodass Clients ihre Daten schnell von mehr Standorten aus lesen können. Welche Eigenschaften sollten diese zusätzlichen Replikate besitzen? Es könnte sich um ausschließlich nicht schreibgeschützte Replikate handeln. Das wäre jedoch nicht empfehlenswert, da das Hinzufügen von nicht schreibgeschützten Replikaten zu einer Konfiguration die Größe des Schreibquorums erhöht. Dies führt möglicherweise zu höheren Netzwerklatenzen, weil mehr Replikate miteinander kommunizieren müssen, vor allem dann, wenn diese sich an geografisch verteilten Standorten befinden. Außerdem erhöht sich nach dem Hinzufügen solcher Replikate die erforderliche Menge an Speicherplatz, da jene jeweils vollständige Kopien der Daten enthalten. Anstelle von mehr nicht schreibgeschützten Replikaten enthalten multiregionale Basiskonfigurationen zwei zusätzliche Arten von Replikaten, die weniger Verantwortlichkeiten als nicht schreibgeschützte Replikate haben.

• Schreibgeschützte Replikate stimmen weder für Leader ab noch darüber, ob Schreibvorgänge festgeschrieben werden. Sie ermöglichen Ihnen also, Ihre Lesekapazität zu skalieren, ohne das Quorum, das für Schreibvorgänge erforderlich ist, zu erhöhen.
• Zeugenreplikaten stimmen über Leader ab und über das Commit von Schreibvorgängen. Sie speichern jedoch keine vollständige Kopie der Daten, können nicht zum Leader werden und keine Lesevorgänge bereitstellen. Sie erleichtern das Erreichen von Schreibquoren, ohne dass die Speicher- und Rechenressourcen benötigt werden, die nicht schreibgeschützte Replikate erfordern, damit Sie eine vollständige Kopie der Daten speichern und Lesevorgänge bedienen können.