Überlegungen zum Entwurf eines einfachen benutzerdefinierten Anbieters
Wie jeder andere Produktionsdatenspeicher sollte ein Datenspeicher, der an Synchronisierungen beteiligt ist, regelmäßig gesichert werden. Beim Wiederherstellen eines Datenspeichers aus einer Sicherung sind im Wesentlichen zwei Punkte zu berücksichtigen:
Änderungen, die im Serverdatenspeicher nach der Wiederherstellung gemacht wurden, werden u. U. nicht an andere Replikate weitergegeben.
Dies kann bei einem ankerbasierten Anbieter auftreten, da der vom Zielanbieter gesendete Anker, der vom Quellenanbieter zum Auflisten von Änderungen verwendet wird, möglicherweise logisch hinter den Änderungen liegt, die nach der Wiederherstellung vorgenommen wurden. Ein ankerbasierter Anbieter sendet beispielsweise Änderungen an einen Zielanbieter, der den Anker speichert, der zum Auflisten von Änderungen verwendet wird. Das Quellreplikat wird aus einer früheren Sicherung wiederhergestellt und Änderungen werden vorgenommen. Die Synchronisierung wird erneut mit den gleichen Quellen- und Zielanbietern ausgeführt. Der Zielanbieter beginnt mit dem Senden des Ankers, der bei der letzten Synchronisierung verwendet wurde. Je nach Erstellungsweise des Ankers erkennt der Quellenanbieter möglicherweise, dass einige der Änderungen, die nach der Wiederherstellung vorgenommen wurden, nicht aufgelistet werden sollten.
Dies kann auch bei einem vollständigen Enumerationsanbieter der Fall sein, da aufgrund der Taktzahl, mit der Versionen zu Änderungen auf dem Quellreplikat zugewiesen wurden, Änderungen möglicherweise als veraltet erkannt werden. Ein vollständiger Enumerationsanbieter sendet beispielsweise Änderungen an einen Zielanbieter. Der Zielanbieter wendet die Änderungen an und aktualisiert sein internes Wissen. Das Quellreplikat wird aus einer früheren Sicherung wiederhergestellt, die eine frühere Taktzahl enthält. Den auf dem Quellreplikat vorgenommenen Änderungen werden anhand dieser früheren Taktzahl Versionen zugeordnet. Die Synchronisierung wird erneut ausgeführt. Einige der vom Quellenanbieter aufgelisteten Änderungen verfügen über eine Taktzahl, die falsch im Zielwissen enthalten ist, und werden so als veraltet erkannt und nicht auf das Zielreplikat angewendet.
In dieser Situation empfiehlt es sich, dem Replikat jedes Mal, wenn es aus einer Sicherung wiederhergestellt wurde, eine neue Replikat-ID zuzuweisen. Dadurch wird das wiederhergestellte Replikat wie ein neues Replikat behandelt, das sämtliche Daten des gesicherten Replikats empfangen hat. Das gesicherte Replikat wird anschließend so behandelt, als sei es aus der Synchronisierungscommunity zurückgezogen worden. Anderen Replikaten in der Synchronisierungscommunity ist das wiederhergestellte Replikat aufgrund der neuen Replikat-ID nicht bekannt. Auf diese Weise werden Elemente, die dem wiederhergestellten Replikat neu hinzugefügt werden, während der Synchronisierung ordnungsgemäß gesendet.
Einfache benutzerdefinierte Anbieter verwenden den Metadaten-Speicherdienst zum Speichern von Metadaten. Daher sind für eine Änderung der Replikat-ID die folgenden Schritte erforderlich.
Implementieren Sie den Anbieter, sodass dieser in einem speziell für das Wiederherstellen aus einer Sicherung entwickelten Modus arbeiten kann. Im Wiederherstellungsmodus wendet der Zielanbieter nur Änderungen an den Metadaten auf das Zielreplikat an. Der Anbieter erkennt keine lokalen Änderungen und wendet die Änderungsdaten nicht auf das Replikat an.
Stellen Sie das Replikat aus einer Sicherung wieder her. Erstellen Sie anschließend zwei Instanzen des Anbieters. Der Quellenanbieter stellt das wiederhergestellte Replikat mit der alten Replikat-ID dar, und der Zielanbieter stellt das wiederhergestellte Replikat mit einer neuen Replikat-ID und einem neuen Metadatenspeicher dar. Setzen Sie den Zielanbieter in den Wiederherstellungsmodus.
Führen Sie eine Synchronisierung vom Quellenanbieter zum Zielanbieter durch. Dadurch wird der neue Metadatenspeicher mit der neuen Replikat-ID aufgefüllt.
Löschen Sie den alten Metadatenspeicher, und verwenden Sie den neuen Metadatenspeicher sowie die neue Replikat-ID, um das Replikat darzustellen. Nun kann die Synchronisierung mit dem Rest der Synchronisierungscommunity durchgeführt werden.
Neue Elemente, die nach der Wiederherstellung erstellt wurden, können möglicherweise zu Namenskonflikten führen, wenn zuvor ein Element mit dem gleichen Namen erstellt und synchronisiert wurde. Ein Quellreplikat speichert beispielsweise Dateien. Der Quellenanbieter sendet eine Erstellungsänderung für eine Datei mit dem Namen „MyChange.txt“. Das Quellreplikat wird aus einer früheren Sicherung wiederhergestellt, in der die Datei MyChange.txt nicht enthalten ist. Der Quellenanbieter erstellt eine neue MyChange.txt-Datei und weist eine neue Element-ID zu. Die Synchronisierung wird erneut ausgeführt. Wenn die Änderung für MyChange.txt gesendet wurde, erkennt der Zielanbieter einen Einschränkungskonflikt zwischen den beiden MyChange.txt-Dateien, da sie den gleichen Namen, jedoch unterschiedliche IDs haben.
In dieser Situation empfiehlt es sich, die Einschränkungskonflikte beim Anbieter zu behandeln. Auf diese Weise werden Namenskonflikte als Einschränkungskonflikte gemeldet und korrekt aufgelöst. Weitere Informationen finden Sie unter Konfliktbehandlung für einfache Anbieter.
Siehe auch
Konzepte
Implementieren eines benutzerdefinierten einfachen Anbieters