Auf dieser Seite wird beschrieben, wie Daten in Spanner repliziert werden, welche verschiedenen Arten 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 Byte-Ebene. Wie unter Lebensdauer von Lese- und Schreibvorgängen von Spanner beschrieben, wird diese Funktion im zugrunde liegenden Dateisystem genutzt, auf dem sie basiert. Spanner schreibt Datenbankmutationen in Dateien in diesem Dateisystem. Das Dateisystem übernimmt die Replikation 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 von Datenverfügbarkeit und geografischer Lokalität zu bieten. Auf übergeordneter Ebene sind alle Daten in Spanner in Zeilen organisiert. Spanner erstellt mehrere Kopien bzw. „Replikate“ dieser Zeilen und speichert diese Replikate dann an verschiedenen geografischen Standorten. Spanner verwendet ein synchrones, Paxos-basiertes Replikationsschema, bei dem abstimmende Replikate bei jeder Schreibanfrage eine Abstimmung vornehmen, bevor der Schreibvorgang festgeschrieben wird. Mit dieser Eigenschaft der global synchronen Replikation können Sie die aktuellen Daten aus jedem nicht schreibgeschützten oder schreibgeschützten Spanner-Replikat lesen.
Spanner erstellt Replikate jedes Datenbank-Splits. Ein Split enthält einen Bereich von zusammenhängenden Zeilen, wobei die Zeilen nach Primärschlüssel geordnet sind. Alle Daten in einem Split werden physisch zusammen im Replikat gespeichert und Spanner stellt jedes Replikat über eine unabhängige Ausfallzone 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 verarbeiten, wenn einige der Replikate nicht verfügbar sind, da nur eine Mehrheit der abstimmenden Replikate erforderlich ist, um einen Schreibvorgang festzuschreiben.
Geografische Präsenz: Die Möglichkeit, Daten mit Spanner auf verschiedene Regionen und Kontinente zu verteilen, bedeutet, dass die Daten geografisch weniger weit entfernt sind und so schneller auf die Nutzer und Dienste zugreifen können, die sie benötigen.
Einheitliche Datenbankerfahrung: Spanner kann aufgrund seiner synchronen Replikation und seiner weltweit hohen Konsistenz eine einzige Datenbankerfahrung bieten.
Erleichterte Anwendungsentwicklung: Da Spanner ACID-konform ist und weltweit eine strikte Konsistenz bietet, müssen Entwickler, die mit Spanner arbeiten, keine zusätzliche Logik in ihre Anwendungen einfügen, um mit Eventual Consistency umzugehen. Dadurch werden die Anwendungsentwicklung und nachfolgende Wartung schneller und einfacher.
Replikattypen
Spanner hat drei Replikattypen: Nicht schreibgeschützte Replikate, schreibgeschützte Replikate und Zeugenreplikate. Die Regionen und Replikationstopologien, aus denen sich die Basisinstanzkonfigurationen zusammensetzen, sind fixiert. Regionale Basisinstanzkonfigurationen verwenden nur nicht schreibgeschützte Replikate, während regionale Basisinstanzkonfigurationen 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 von Spanner-Replikaten und ihre Eigenschaften zusammengefasst:
| Replikattyp | Kann abstimmen | Kann Leader werden | Kann Lesevorgänge verarbeiten | Kann 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 nicht für Leader oder für Commits für Schreibvorgänge ab, sodass Sie die Lesekapazität skalieren können, ohne die Quorumgröße zu erhöhen, die für Schreibvorgänge benötigt wird. 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 Abstimmungen über Schreibvorgänge teil. Daher besitzt der Speicherort der schreibgeschützten Replikate keinen Einfluss auf die Schreiblatenz.
Wenn es das Ihrer Anwendung am nächsten gelegene Replikat ist, kann das schreibgeschützte Replikat in der Regel veraltete Lesevorgänge verarbeiten, ohne dass ein Umlauf zur standardmäßigen führenden Region erforderlich ist. Dabei wird vorausgesetzt, dass die Veralterung mindestens 15 Sekunden beträgt. Sie können gerichtete Lesevorgänge auch 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 gerichtete Lesevorgänge.
Starke Lesevorgänge erfordern möglicherweise einen Umlauf zum Leader-Replikat. Der Umlauf dient nur dazu, den Zeitstempel auszuhandeln und nicht die tatsächlichen Daten vom Leader zu senden. Die Zeitstempelaushandlung ist ein CPU-effizienter Vorgang am Leader und in der Regel sind die Daten bereits unterwegs. Diese Kommunikation wird automatisch vom System abgewickelt.
Weitere Informationen zu veralteten und starken Lesevorgängen finden Sie im Abschnitt zu 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 Standorte, die unter Optionale Region aufgeführt sind, als optionales schreibgeschütztes Replikat hinzufügen. Wenn der ausgewählte Speicherort für schreibgeschützte Replikate nicht angezeigt wird, können Sie eine neue optionale Region für schreibgeschützte Replikate anfordern. Sie können die Replikationstopologie von Basisinstanzkonfigurationen nicht ändern, da diese festgelegt sind.
Für alle optionalen schreibgeschützten Replikate gelten Computing-Kapazitäts- und Speicherkosten. Außerdem ändert sich durch das Hinzufügen von schreibgeschützten Replikaten zu einer benutzerdefinierten Instanzkonfiguration nicht die Spanner-SLAs der Instanzkonfiguration. Wenn Sie einem Kontinent, der sich auf einem anderen Kontinent als der führenden Region befindet, ein schreibgeschütztes Replikat hinzufügen möchten, empfehlen wir, mindestens zwei schreibgeschützte Replikate hinzuzufügen. Dadurch wird eine niedrige Leselatenz für den Fall aufrechterhalten, dass eines der schreibgeschützten Replikate nicht mehr verfügbar ist.
Wenn Sie schreibgeschützte Replikate hinzufügen, steigt die Replikationslast des Leader-Replikats, was die Leistung beeinträchtigen kann. Als Best Practice sollten Sie zuerst Leistungsarbeitslasten in Nicht-Produktionsinstanzen in der benutzerdefinierten Instanzkonfiguration testen. Im Benchmark-Dashboard für die Latenz und den Durchsatz zwischen Regionen finden Sie Daten zum Medianwert der 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 für die führende Region in europe-west4 etwa 100 Millisekunden. Veraltete Lesevorgänge, die ausreichend veraltet sind, werden für den Umlauf nicht ausgeführt und sind daher viel schneller. Sie können auch den Messwert Latenz nach Transaktionstyp verwenden, um Latenzdaten für Lese-/Schreib- und schreibgeschützte Transaktionen anzusehen.
Eine Anleitung dazu 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.
- Bewahren Sie keine vollständige Kopie der Daten auf.
- Keine Lesevorgänge bereitstellen.
- 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 von Spanner beschrieben. So können Sie besser verstehen, warum Spanner Zeugenreplikate in multiregionalen Konfigurationen verwendet.
Bei Schreibvorgängen
Client-Schreibanfragen werden immer zuerst am Leader-Replikat verarbeitet, auch wenn ein Replikat ohne Leader ist, das sich näher am Client befindet, oder wenn 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 das Leader-fähige Routing, um Lese-Schreib-Transaktionen dynamisch weiterzuleiten und so die Latenz in der 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 Lese- oder Schreibschutz weitergeleitet, das bis zum Zeitstempel der Anfrage aktuell ist. Dies kann das Leader-Replikat sein, wenn das Leader-Replikat dem Client, der die Leseanfrage ausgestellt hat, am nächsten ist.