Mit eXtreme Scale kann eine speicherinterne Datenbank oder ein Shard von einer Java Virtual Machine (JVM) in einer anderen repliziert werden. Ein Shard stellt eine Partition dar, die in einen Container gestellt wird. Mehrere Shards, die unterschiedliche Partitionen darstellen, können in einem einzigen Container enthalten sein. Jede Partition hat eine Instanz, die ein primäres Shard ist, und eine konfigurierbare Anzahl an Replikat-Shards. Die Replikat-Shards sind synchron der asynchron. Die Typen und die Verteilung der Replikat-Shards werden von eXtreme Scale über eine Implementierungsrichtlinie bestimmt, die die Mindest- und Maximalanzahl synchroner und asynchroner Shards festlegt.
Für die Replikation werden drei Typen von Shards verwendet:
Das primäre Shard empfängt alle Einfüge-, Aktualisierungs- und Entfernungsoperationen. Das primäre Shard fügt Replikate hinzu und entfernt Replikate, repliziert Daten in den Replikaten und verwaltet Commit- und Rollback-Operationen für Transaktionen.
Synchrone Replikate haben denselben Status wie das primäre Shard. Wenn ein primäres Shard Daten in einem synchronen Replikat repliziert, wird die Transaktion erst festgeschrieben, wenn sie im synchronen Replikat festgeschrieben wurde.
Asynchrone Replikate können denselben Status haben wie das primäre Shard. Wenn ein primäres Shard Daten in einem asynchronen Replikat repliziert, wartet das primäre Shard nicht auf die Festschreibung durch das asynchrone Replikat.
Wenn ein primäres Shard die Festschreibung von Daten vorbereitet, prüft es, wie viele synchrone Replikat-Shards für die Festschreibung der Transaktion gestimmt haben. Wenn die Transaktion im Replikat normal verarbeitet wird, stimmt das Replikat der Festschreibung zu. Wenn im synchronen Replikat etwas schiefgelaufen ist, stimmt das Replikat der Festschreibung nicht zu. Bevor ein primäres Shard Daten festschreibt, muss die Anzahl synchroner Replikat-Shards, die für die Festschreibung gestimmt haben, der minSyncReplica-Einstellung in der Implementierungsrichtlinie entsprechen. Wenn die Anzahl synchroner Replikat-Shards, die der Festschreibung zustimmen, zu niedrig ist, schreibt das primäre Shard die Transaktion nicht fest, und es tritt ein Fehler auf. Diese Aktion stellt sicher, dass die erforderliche Anzahl synchroner Replikate mit den korrekten Daten verfügbar ist. Synchrone Replikate, in denen Fehler aufgetreten sind, nehmen ihre Registrierung zurück, um ihren Zustand zu korrigieren. Weitere Informationen zum Zurücknehmen der Registrierung finden Sie im Abschnitt Wiederherstellung von Replikat-Shards.
Das primäre Shard löst eine Fehler des Typs "ReplicationVotedToRollbackTransactionException" aus, wenn die Anzahl synchroner Replikate, die der Festschreibung zugestimmt haben, zu niedrig ist.
Normalerweise schreibt ein primäres Shard synchron über den Loader in eine Datenbank. Der Loader und die Datenbank sind immer synchronisiert. Wenn das primäre Shard von einem Replikat-Shard übernommen wird, sind die Datenbank und der Loader möglicherweise nicht mehr synchronisiert. Beispiel:
Beide Fälle führen dazu, dass das Replikat mit einer Transaktion gegenüber der Datenbank im Vorlauf bzw. im Rückstand ist. Diese Situation ist nicht akzeptabel. eXtreme Scale verwendet ein spezielles Protokoll und einen Vertrag mit der Loader-Implementierung, um dieses Problem ohne zweiphasige Festschreibung zu lösen. Das Protokoll folgt:
Seite des primären Shard
Replikatseite
Replikatseite bei Failover
Dieses Protokoll stellt sicher, dass die Datenbank denselben Stand wie das neue primäre Shard hat.