Schließlich einheitliches Design, Latenz und Rückstand
Eine Replikationsgruppe ist konsistent, wenn SQL-Abfragen auf einem Replikationsknoten der Gruppe auf allen Replikationsknoten der Gruppe das gleiche Ergebnis liefern. Um die Datenbanken auf verschiedenen Knoten identisch zu halten, verwendet IBM® Netezza® Replication Services die Methode "eventually consistent".
Bei der eventuell konsistenten Methode kann es vorkommen, dass ein Knoten (der primäre) einen neueren Datenbankinhalt hat als die anderen. Die Zeitspanne, um die das Replikat hinter dem Primärsystem zurückbleibt, wird als Latenzzeit bezeichnet, und die Datenmenge, die vom Replikat repliziert und angewendet werden muss, ist der Backlog.
Latenzzeit und Rückstand hängen von der spezifischen Konfiguration und Arbeitslast ab. Die spezifischen Ursachen für die Latenz in IBM Netezza Replication Services sind wie folgt:
- Die Fähigkeit der primären Knoten, SQL-Aktualisierungstransaktionen (z. B. INSERT, DELETE oder UPDATE) für replizierte Daten parallel durchzuführen, hängt von den aktuellen Isolierungsebenen der Transaktionen ab (die seriell oder als Snapshot-Isolierung erfolgen können). Die Replikate führen die replizierten Transaktionen seriell in der Reihenfolge aus, in der sie auf dem Primärsystem übertragen wurden. Die Zeit, die für den Abschluss einer Reihe gleichzeitiger replizierter Transaktionen auf der Primärseite benötigt wird, entspricht der Zeit, die die längste Transaktion benötigt. Die Zeit, die benötigt wird, um dieselben Transaktionen auf einem Replikat abzuschließen, ist jedoch die Summe der Zeiten für die Ausführung der einzelnen Transaktionen.
- Die Daten der Ladedatei werden auf die Replikat-Hosts repliziert, nachdem sie auf dem Primärhost vollständig geladen wurden. Alle Daten der Ladedatei werden zunächst vollständig im Protokoll des primären Replikationswarteschlangenmanagers erfasst und dann an das Replikat übertragen. Erst wenn alle Daten für einen Vorgang vollständig übertragen sind, beginnt die Replik mit der Anwendung der Daten. Die Zeit für die Übertragung des Replikationsprotokolls ergibt sich aus der Gesamtdatenmenge geteilt durch die fensterbegrenzte Bandbreite der Verbindung des Replikationswarteschlangenmanagers und trägt direkt zur Latenzzeit bei. Bei mehreren sequenziellen Loads in derselben Transaktion wartet IBM Netezza Replication Services nicht, bis alle Loads abgeschlossen sind, bevor die Übertragung beginnt; die Latenzzeit liegt zwischen der Zeit für die Übertragung des letzten großen Loads und der Zeit für die Übertragung aller Daten.
Das letztendlich konsistente Design hat Auswirkungen auf Anwendungen, die IBM Netezza Replication Services für größere Implementierungen nutzen. Einige Überlegungen zur Gestaltung lauten wie folgt:
- Abfragen, die mit einer Latenzzeit von Null ablaufen müssen, müssen auf der aktuellen Primärseite durchgeführt werden. Der aktuelle Primärserver kann in den Betriebsansichten des Replikationssets ermittelt werden.
- Anwendungen, die Abfragen mit geringer Latenz ausführen müssen, überprüfen die Betriebsansichten des Replikationssets, um die aktuelle Latenz der Replikate zu ermitteln, und leiten die Abfragen dann an Replikate weiter, deren Latenz innerhalb akzeptabler Grenzen liegt.
- Latenzunabhängige Abfragen können an jeden NPS-Knoten im Replikationsset gesendet werden.
- Sie können Abfragen entwerfen, um Zeilendaten wie Datum, Uhrzeit, Batchlauf oder andere identifizierende Spaltenwerte zu verwenden, um Ergebnisse auszuschließen, die neuer als ein bestimmter Wert sind.