Instanzübergreifende Datenreplikation erkunden

Instanzübergreifende Datenreplikation (HLA) bietet eine 1:n-Replikation, mit der eine Instanz Daten über verschiedene Abteilungen und Geschäftsbereiche hinweg verteilen und die Daten synchronisieren kann.

HLA unterstützt auch die bidirektionale Replikation. Mit der bidirektionalen Replikation können Sie Daten von einer Erstellerinstanz in eine Verbraucherinstanz und von einer Verbraucherinstanz zurück in die Erstellerinstanz kopieren.

Vorteile

• Daten werden automatisch in mindestens einer weiteren Instanz repliziert.
• Daten können geändert und jeder Tabelle und Tabellenspalte in anderen Instanzen zugeordnet werden. Sie können beispielsweise Tabellenspalten ändern und zuordnen, um Daten für verschiedene Gebietsschemata zu lokalisieren.
• Daten, die in Verbraucherinstanzen aktualisiert werden, können zur Erstellerinstanz repliziert werden.

  Daten wie Problemanforderungen können zur Verwendung durch Drittparteien in Verbraucherinstanzen kopiert werden. Die Drittpartei kann das Problem in der Verbraucherinstanz aktualisieren. Die Daten können dann in der Herstellerinstanz aktualisiert werden.

• Geschäftsregeln können Workflows nach der Replikationauslösen, z. B. das Generieren von Benachrichtigungen oder das Validieren der Replikation.
• Daten, die während eines Absturzes übertragen werden, können wiederhergestellt werden.

Funktionsweise von Instanzübergreifende Datenreplikation

Sie verwenden das Plugin Instanzübergreifende Datenreplikation (com.glide.idr), um Datenaktualisierungen in einer Instanz, die als Erstellerinstanz bezeichnet wird, an eine oder mehrere andere Instanzen, die als Verbraucherinstanzen bezeichnet werden, zu replizieren.

Durch die Konfiguration eines Erstellerreplikationssatzes können Sie die zu replizierenden Tabellen und Tabellenspalten in der Erstellerinstanz angeben. Wenn Sie einen Verbraucherdatensatz konfigurieren, können Sie die Tabellen und Tabellenspalten in den Verbraucherinstanzen angeben, die die Daten des Erstellerreplikationssatzes empfangen.

Als Nächstes aktivieren Sie Ersteller- und Verbraucherreplikationssätze, um die HLA -Funktionalität zu aktivieren. Die Daten, die in einem Erstellerreplikationssatz aktualisiert werden, aktualisieren automatisch die entsprechenden Daten in den Verbraucherreplikationssätzen.

Das Synchronisieren der Ersteller- und Verbraucherreplikationssätze erfordert einen einmaligen Download ( Seedinggenannt) aller Ersteller-Replikationssätze in die Verbraucherinstanzen.

Sie können Seeding-Anforderungen für eine Verbraucherinstanz initiieren, wenn Sie einen Verbraucherreplikationssatz aktivieren. Ab Release Rome können Sie eine Filterkriterienfunktion ( partielles Seeding) verwenden, um die Anzahl der Datensätze, für die ein Seeding durchgeführt wird, einzuschränken. Verwenden Sie teilweise Seeding, um große Aufgaben in kleinere Aufgaben aufzuteilen, wenn Sie eine große Anzahl von Datensätzen duplizieren müssen.

Nach dem Seeding umfasst die Replikation nur Datenaktualisierungen. Ein Audit-Pfad enthält einen Verlauf dieser Datensatzaktualisierungen.

Standardmäßig werden die Tabellendaten einer Erstellerinstanz in die gleichnamigen Tabellen der Verbraucherinstanzen eingefügt. Transformation ist der Prozess der Replikation von Erstellerdaten in Tabellen oder Tabellenspalten, die in den Verbraucherinstanzen einen anderen Namen haben.

HLA -Adapter ändern Daten, bevor sie in Verbraucherinstanzen gespeichert werden. Adapter führen Zeichenfolgenoperationen und mathematische Berechnungen durch, z. B. das Konvertieren einer Währung in eine andere oder das Konvertieren einer Zeitzone in eine andere.

Abbildung : 1. HLA – Übersicht

Warnung:

HLA überschreibt Daten in Instanzen und kann vertrauliche Daten replizieren. Vermeiden Sie potenziellen Datenverlust und Datenrisiken, indem Sie Ihre HLA -Implementierung in einer Vorproduktionsumgebung testen. Weitere Informationen finden Sie unter Datenschutz in IDR.

Legacy- und V2-Replikationssätze

HLA unterstützt sowohl Legacy- als auch V2-Replikationssätze. Ab Release Washington DC können Sie keine Legacy-Replikationssätze mehr erstellen.

• Legacy-Replikationssätze verwenden eine Implementierung für den Transport und die Zustellung von Kafka-Nachrichten ServiceNow, die vor dem Release Utah erstellt wurde. Alle Replikationssätze, die vor Release Utah erstellt wurden, gelten als Legacy-Replikationssätze.
• V2-Replikationssätze verwenden ServiceNow Hermes Messaging-Service für den Transport und die Zustellung von Kafka-Nachrichten. Hermes Messaging-Service ist eine Now Platform -Fähigkeit, die es HLA ermöglicht, Daten schneller und skalierbarer zu replizieren.

Legacy-Erstellerreplikationssätze sind nur mit Legacy-Verbraucherreplikationssätzen kompatibel. Ebenso sind V2-Erstellerreplikationssätze nur mit V2-Verbraucherreplikationssätzen kompatibel.

Sie können entweder neue V2-Replikationssätze erstellen oder vorhandene Legacy-Replikationssätze auf V2 aktualisieren. Weitere Informationen finden Sie unter Upgrade von Legacy-Replikationssätzen auf V2 in Instanzübergreifende Datenreplikation.

HLA und Instanz-Upgrades durchführen

Das Upgrade Ihrer -Instanz mit aktiviertem HLA ist ein nahtloser Prozess.

• HLA verbraucht oder erzeugt während eines Instanz-Upgrades keine Nachrichten. HLA -Aufträge werden zu Beginn des Upgrades automatisch beendet.
• „data_replication_queue“ verfolgt den Zeitstempel der letzten gesendeten Nachricht. Dadurch wird sichergestellt, dass die Replikation ab der letzten Änderung vor dem Upgrade fortgesetzt wird.
• Jedes vor dem Upgrade laufende Seeding wird beim Start des Upgrades automatisch angehalten und nach Abschluss des Upgrades fortgesetzt. Um sicherzustellen, dass das Seeding ohne Unterbrechungen abgeschlossen wird, vermeiden Sie es, vor einem Upgrade eine Seeding-Anforderung zu initiieren.
• Seeding-Anforderungen können nicht während eines Instanz-Upgrades initiiert werden.
• Die Replikation wird unmittelbar nach Abschluss des Upgrades fortgesetzt. Es müssen keine Anpassungen an HLA vorgenommen werden, damit die Datensatzreplikation fortgesetzt wird.

HLA Einschränkungen und wann Sie sie nicht verwenden sollten HLA

• Verwenden Sie HLA nicht zum Klonen von Instanzen.

  HLA repliziert keine Metadatentabellen, untergeordneten Metadatentabellen und die meisten Benutzer- und Systemtabellen. HLA wurde zum Replizieren von Daten entwickelt, nicht zum Klonen von Instanzen. Beispielsweise sind die Tabelle „Anwendungsdatei“ [sys_metadata] und Tabellen, die [sys_metadata] erweitern (einschließlich der Tabellen „Business-Regeln“ [sys_script], „Katalog“ [sc_catalog] und „Workflow“ [wf_workflow]), ausgeschlossen und können nicht repliziert werden. Weitere Informationen zum Klonen finden Sie unter System clone.

• Vermeiden Sie die Verwendung von HLA, um eine Reihe großer Anhänge regelmäßig zu replizieren. Wenn Sie regelmäßig Anhänge einschließen müssen, die größer als 10 MB sind, überwachen Sie HLA, um sicherzustellen, dass die Verzögerungszeit die Erwartungen nicht überschreitet.
• Vermeiden Sie das Replizieren von CMDB -Tabellen. Wenn Sie feststellen, dass die Tabellen repliziert werden müssen, müssen Sie Bedingungen verwenden, um die Anzahl der replizierten Datensätze einzuschränken und sicherzustellen, dass alle erforderlichen Spalten im Replikationssatz enthalten sind.
• Die Felder „Edge Encrypted“, „Spalte Level Encryption“ (CLE) und „Passwort“ (zweifach verschlüsselt) können nicht repliziert werden.
• Einschränkungen für das Replizieren von aktualisierten Datensätzen:
  • Die maximale Datensatzgröße beträgt 32 MB.
  • HLA unterstützt die Replikation von etwa 1 Million Datensätzen pro Tag.
• Einschränkungen für Seeding-Datensätze:
  • Das Replikations-Seeding darf nicht länger als sieben Tage dauern.
  • Das anfängliche Seeding der Tabellen darf 3 Millionen Datensätze pro Replikationssatz nicht überschreiten.
  Hinweis:

  Um diese Einschränkungen zu umgehen, reduzieren Sie die Anzahl der Tabellen in der Seeding-Anforderung, reduzieren Sie die Größe der Datensätze, oder verwenden Sie teilweises Seeding.