Koordiniertes Replicat

Im koordinierten Modus funktioniert Replicat wie folgt:

Der Unterschied zwischen klassischem und koordiniertem Modus besteht darin, dass Replicat im koordinierten Modus Multi-Threaded ist. Innerhalb einer einzelnen Replicat-Instanz lesen mehrere Threads den Trail unabhängig voneinander und wenden Transaktionen parallel an. Jeder Thread verarbeitet die Filterung, Zuordnung, Konvertierung, SQL-Konstruktion und Fehlerbehandlung für die zugewiesene Workload. Ein Koordinator-Thread koordiniert die Transaktionen über Threads hinweg, um Abhängigkeiten zwischen den Threads zu berücksichtigen.

Die Quelltransaktionen können so auf CR-Prozesse aufgeteilt werden, dass die Integrität der gesamten Quelltransaktion nicht erhalten bleibt. Der von einem CR-Prozess verarbeitete Teil der Transaktion wird in zugesagter Reihenfolge ausgeführt, die gesamte Transaktion über alle CR-Prozesse hinweg ist dies jedoch nicht.

Coordinated Replicat ermöglicht eine benutzerdefinierte Partitionierung der Workload, um Transaktionen mit hohem Volumen gleichzeitig anzuwenden. Darüber hinaus koordiniert es automatisch die Ausführung von Transaktionen, die eine Koordination erfordern, wie DDL und Primärschlüsselaktualisierungen mit der THREADRANGE-Partitionierung. Eine solche Transaktion wird als eine Transaktion im Ziel mit vollständiger Synchronisierung ausgeführt: Sie wartet, bis alle vorherigen Transaktionen zuerst angewendet werden, und alle Transaktionen nach dieser Sperrtransaktion müssen warten, bis diese Sperrtransaktion angewendet wird.

Für ein koordiniertes Replicat ist unabhängig von der Anzahl der Threads nur eine Parameterdatei erforderlich. Mit der Option THREAD oder THREADRANGE in der MAP-Anweisung geben Sie an, welche Threads die Transaktionen für diese Objekte verarbeiten. Außerdem geben Sie die maximale Anzahl von Threads an, wenn Sie die Replicat-Gruppe erstellen.

In dieser Abbildung wird die Architektur von Coordinated Replicat dargestellt.

Beschreibung von coordinatedreplicat.jpg folgt

Wie in dieser Abbildung dargestellt, umfasst das koordinierte Replicat die folgenden beiden Prozesse:

Informationen zu Barrier-Transaktionen

Barrierentransaktionen werden automatisch in einer koordinierten Replicat-Konfiguration verwaltet. Barrieretransaktionen sind Transaktionen, die eine Koordination zwischen Threads erfordern. Beispiele sind DDL-Anweisungen, Transaktionen, die Aktualisierungen von Primärschlüsseln enthalten, und bestimmte EVENTACTIONS-Aktionen.

Optional können Sie erzwingen, dass andere Transaktionen wie eine Sperrtransaktion behandelt werden, indem Sie den Befehl "COORDINATED keyword in a MAP statement. One use case for this would be force a SQLEXEC" verwenden, der einer seriellen Ausführung ähnelt. Dies kann von Vorteil sein, wenn die Ergebnisse mehrdeutig werden können, es sei denn, der Status des Ziels ist über alle Transaktionen hinweg konsistent.

Hinweis: Coordinated Replicat führt keine Abhängigkeitsberechnungen für Nicht-Barriere-Transaktionen durch, wenn eine zugeordnete Tabelle basierend auf THREADRANGE partitioniert wird. Es basiert auf angegebenen THREADRANGE-Spalten, um einen Hashwert zu berechnen. Es partitioniert die eingehenden Daten basierend auf dem Hash-Wert und sendet alle Datensätze, die diesem Hash-Wert entsprechen, an denselben Thread.

Verarbeitung von Barrieretransaktionen

Alle Threads konvergieren und warten zu Beginn einer Sperrentransaktion. Die Sperrungstransaktion wird solange unterbrochen, bis die anderen Fäden ihre Startposition erreichen. Wenn Threads bereits einen Teil der Barrieretransaktion verarbeiten, führen diese Threads ein Rollback aus. Gruppierte Transaktionen, wie sie durch die Parameter BATCHSQL oder GROUPTRANSOPS gesteuert werden, werden ebenfalls zurückgerollt und dann erneut angewendet, bis sie den Start der Sperrtransaktion erreichen.

Alle Threads konvergieren und warten zu Beginn der nächsten Transaktion auch nach der Sperrtransaktion. Die beiden Synchronisierungspunkte vor und nach der Sperrentransaktion stellen sicher, dass Metadatenvorgänge und EVENTACTIONS-Aktionen in der für die Datenvorgänge relevanten Reihenfolge ausgeführt werden.

Sobald die Threads zu Beginn der Barriere-Transaktion synchronisiert werden, wird die Barriere-Transaktion seriell von dem Thread verarbeitet, der die niedrigste Thread-ID unter allen in den MAP-Anweisungen angegebenen Threads aufweist, und dann wird die parallele Verarbeitung über Threads fortgesetzt. Sie können erzwingen, dass Sperrtransaktionen über einen bestimmten Thread verarbeitet werden, der immer Thread 0 ist, indem Sie den Parameter USEDEDICATEDCOORDINATIONTHREAD in der Replicat-Parameterdatei angeben.