Replikate und Shards

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.

Shard-Typen

Für die Replikation werden drei Typen von Shards verwendet:

  • primäre Shards,
  • synchrone Replikate,
  • asynchrone Replikate.

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.

Abbildung 1. Kommunikationspfad zwischen einem primären Shard und einem Replikat-Shard
Eine Transaktion kommuniziert mit einem primären Shard. Das primäre Shard kommuniziert mit Replikat-Shards, die in einer oder mehreren Java Virtual Machines ausgeführt werden können.

Mindestanzahl synchroner Replikat-Shards

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.

Replikation und Loader

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:

  • Das primäre Shard kann die Transaktion an das Replikat senden und dann vor der Festschreibung der Daten in der Datenbank ausfallen.
  • Das primäre Shard kann die Daten in der Datenbank festschreiben und dann vor dem Senden der Daten an das Replikat ausfallen.

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

  • Transaktion zusammen mit den vorherigen Transaktionsergebnissen senden.
  • In die Datenbank schreiben und versuchen, die Transaktion festzuschreiben.
  • Wenn die Datenbank festschreibt, dann in eXtreme Scale festschreiben. Wenn die Datenbank nicht festschreibt, Transaktion rückgängig machen.
  • Ergebnis aufzeichnen.

Replikatseite

  • Transaktion empfangen und puffern.
  • Für alle Ergebnisse, die mit der Transaktion geändert werden, die gepufferten Transaktionen festschreiben und alle rückgängig gemachten Transaktionen verwerfen.

Replikatseite bei Failover

  • Für alle gepufferten Transaktionen die Transaktionen dem Loader bereitstellen, und der Loader versucht, die Transaktionen festzuschreiben.
  • Der Loader muss so geschrieben sein, dass jede Transaktion idempotent ist.
  • Wenn die Transaktion bereits in der Datenbank vorhanden ist, führt der Loader keine Operation durch.
  • Wenn die Transaktion noch nicht in der Datenbank vorhanden ist, wendet der der Loader die Transaktion an.
  • Nachdem alle Transaktionen verarbeitet wurden, kann das neue primäre Shard mit der Bearbeitung der Anforderungen beginnen.

Dieses Protokoll stellt sicher, dass die Datenbank denselben Stand wie das neue primäre Shard hat.