Instanzübergreifende Datenreplikation erkunden

Instanzübergreifende Datenreplikation (IDR) bietet eine 1:n-Replikation, die es einer Instanz ermöglicht, Daten über verschiedene Abteilungen und Geschäftsbereiche hinweg zu verbreiten, um die Daten zu synchronisieren.

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

Vorteile

• Daten werden automatisch in eine oder mehrere andere Instanzen 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 in die Erstellerinstanz repliziert werden.

  Daten, z. B. 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 Produzenteninstanz aktualisiert werden.

• Business Rules 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, der sogenannten Produzenteninstanz, in einer oder mehreren anderen Instanzen, den sogenannten Verbraucherinstanzen, 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 sowohl Ersteller- als auch Verbraucherreplikationssätze, um die IDR -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 (sogenanntes Seeding) aller Erstellerreplikationssatzdaten in die Verbraucherinstanzen.

Sie können Seeding-Anforderungen für eine Verbraucherinstanz initiieren, wenn Sie einen Verbraucherreplikationssatz aktivieren. Ab dem Release Rome können Sie eine Filterkriteriumsfunktion ( partielles Seeding) verwenden, um die Anzahl der Datensätze zu beschränken, für die ein Seeding durchgeführt wird. Verwenden Sie partielles 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 Auditpfad enthält einen Verlauf dieser Datensatzaktualisierungen.

Standardmäßig werden die Tabellendaten in einer Produzenteninstanz in die gleichnamigen Tabellen in Verbraucherinstanzen eingefügt. Bei derTransformation werden Erstellerdaten in Tabellen oder Tabellenspalten repliziert, die in den Verbraucherinstanzen einen anderen Namen haben.

IDR Adapter ändern Daten, bevor sie in Verbraucherinstanzen gespeichert werden. Adapter führen Zeichenfolgen- und mathematische Operationen aus, z. B. die Konvertierung einer Währung in eine andere oder die Konvertierung einer Zeitzone in eine andere.

Abbildung : 1. IDR – Übersicht

Warnung:

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

Legacy- und V2-Replikationssätze

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

• Veraltete Replikationssätze verwenden eine ServiceNow Implementierung von Kafka-Nachrichtentransport und -zustellung, die vor dem Utah -Release erstellt wurde. Alle Replikationssätze, die vor dem Release Utah erstellt wurden, werden als veraltete Replikationssätze betrachtet.
• V2-Replikationssätze verwenden ServiceNow Hermes Messaging-Service für Kafka-Nachrichtentransport und -zustellung. Hermes Messaging-Service ist eine Fähigkeit von Now Platform, mit der IDR Daten schneller und skalierbarer replizieren kann.

Veraltete Erstellerreplikationssätze sind nur mit veralteten 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 ältere Replikationssätze auf V2 aktualisieren. Weitere Informationen finden Sie unter Upgrade veralteter Replikationssätze auf V2 in Instanzübergreifende Datenreplikation.

IDR Einschränkungen und nicht zu verwenden IDR

• Verwenden Sie IDR nicht zum Klonen von Instanzen.

  IDR repliziert keine Metadatentabellen, untergeordneten Metadatentabellen und die meisten Benutzer- und Systemtabellen. IDR dient dazu, Daten zu replizieren und keine Instanzen zu klonen. Beispielsweise werden die Tabelle „Anwendungsdatei“ [sys_metadata] und Tabellen, die [sys_metadata] erweitern (einschließlich der Tabellen „Business Rules“ [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 es, IDR zu verwenden, um eine Reihe großer Anhänge regelmäßig zu replizieren. Wenn Sie regelmäßig Anhänge einbeziehen müssen, die größer als 10 MB sind, überwachen Sie IDR, um sicherzustellen, dass die Verzögerungszeit die Erwartungen nicht überschreitet.
• Vermeiden Sie die Replizierung von CMDB -Tabellen. Wenn Sie bestimmen, dass die Tabellen repliziert werden müssen, müssen Sie Bedingungen verwenden, um die Anzahl der replizierten Datensätze zu beschränken und sicherzustellen, dass alle erforderlichen Spalten im Replikationssatz enthalten sind.
• Sie können die Felder Edge Encrypted, CLE (Spaltenebenenverschlüsselung) und Passwort (zweifach verschlüsselt) nicht replizieren.
• Einschränkungen für die Replizierung aktualisierter Datensätze:
  • Die maximale Datensatzgröße beträgt 32 MB.
  • IDR 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 überwinden, reduzieren Sie die Anzahl der Tabellen in der Seeding-Anforderung, reduzieren Sie die Größe der Datensätze, oder verwenden Sie partielles Seeding.