Considerazioni relative alla progettazione di provider personalizzati semplici
Come qualsiasi altro archivio dati di produzione, un archivio dati interessato da una sincronizzazione deve essere sottoposto a backup con regolarità. Prima di ripristinare un archivio dati da un backup, è opportuno tenere presenti due considerazioni principali:
Le modifiche effettuate nell'archivio dati dopo il ripristino potrebbero non venire propagate ad altre repliche.
Questa situazione può verificarsi in un provider basato su ancoraggio perché l'ancoraggio inviato dal provider di destinazione e utilizzato dal provider di origine per enumerare le modifiche può essere logicamente successivo alle modifiche apportate dopo il ripristino. Ad esempio, un provider basato su ancoraggio invia modifiche a un provider di destinazione che salva l'ancoraggio utilizzato per enumerare le modifiche. La replica di origine viene ripristinata da un backup precedente e vengono apportate modifiche. La sincronizzazione viene nuovamente eseguita con gli stessi provider di origine e di destinazione. Il provider di destinazione inizia a inviare l'ancoraggio utilizzato durante l'ultima sincronizzazione. A seconda della modalità di creazione dell'ancoraggio, è possibile che il provider di origine rilevi che alcune modifiche apportate dopo il ripristino non devono essere enumerate.
Questa situazione può verificarsi in un provider di enumerazione completa perché il conteggio utilizzato per assegnare versioni alle modifiche nella replica di origine può far sì che le modifiche vengano rilevate come obsolete. Ad esempio, un provider di enumerazione completa invia modifiche a un provider di destinazione. Il provider di destinazione applica le modifiche e aggiorna la propria conoscenza interna. La replica di origine viene ripristinata da un backup precedente, che include un conteggio precedente. Alle modifiche apportate nella replica di origine vengono assegnate versioni in base al conteggio precedente. La sincronizzazione viene nuovamente eseguita. Alcune delle modifiche enumerate dal provider di origine presentano un conteggio incluso erroneamente nella conoscenza di destinazione, pertanto vengono rilevate come obsolete e non vengono applicate alla replica di destinazione.
La soluzione consigliata per questa situazione consiste nell'assegnare un nuovo ID replica a una replica ogni volta che viene ripristinata da un backup. La replica ripristinata viene in questo modo gestita come una nuova replica che abbia ricevuto tutti i relativi dati dalla replica di cui è stato eseguito il backup e la replica di cui è stato eseguito il backup viene gestita come una replica disattivata nella community di sincronizzazione. Le altre repliche incluse nella community di sincronizzazione non sono a conoscenza della replica ripristinata a causa del nuovo ID replica, pertanto i nuovi elementi aggiunti alla replica ripristinata verranno inviati correttamente durante la sincronizzazione.
I provider personalizzati semplici utilizzano i servizi di archiviazione dei metadati per archiviare i metadati, pertanto la modifica dell'ID replica richiede l'esecuzione dei passaggi seguenti:
Implementare il provider in modo da poterlo utilizzare in una modalità speciale progettata per il ripristino da un backup. Nella modalità di ripristino, il provider di destinazione applica alla replica di destinazione solo le modifiche apportate ai metadati. Il provider non rileva le modifiche locali e non applica i dati di modifica alla replica.
Ripristinare la replica da un backup. Dopo aver ripristinato la replica da un backup, creare due istanze del provider. Il provider di origine rappresenta la replica ripristinata con l'ID replica precedente, mentre il provider di destinazione rappresenta la replica ripristinata con un nuovo ID replica e un nuovo archivio dei metadati. Attivare la modalità di ripristino per il provider di destinazione.
Eseguire la sincronizzazione dal provider di origine al provider di destinazione. In questo modo il nuovo archivio dei metadati verrà popolato con il nuovo ID replica.
Eliminare l'archivio dei metadati precedente e utilizzare il nuovo archivio dei metadati e il nuovo ID replica per rappresentare la replica. Sarà quindi possibile eseguire la sincronizzazione con la parte restante della community di sincronizzazione.
I nuovi elementi creati dopo il ripristino possono provocare conflitti di nomi se in precedenza è stato creato e sincronizzato un elemento con lo stesso nome. Ad esempio, una replica di origine archivia file. Il provider di origine invia una modifica della creazione per un file denominato "MyChange.txt". La replica di origine viene ripristinata da un backup precedente che non contiene MyChange.txt. Viene creato un nuovo file MyChange.txt a cui il provider di origine assegna un nuovo ID elemento. La sincronizzazione viene nuovamente eseguita. Quando viene inviata la modifica per MyChange.txt, il provider di destinazione rileva un conflitto tra vincoli tra i due file MyChange.txt, in quanto presentano lo stesso nome ma ID elemento diversi.
La soluzione consigliata per questa situazione consiste nel gestire i conflitti tra vincoli nel provider. In questo modo, i conflitti di nomi che si verificano vengono segnalati come conflitti tra vincoli e risolti in modo corretto. Per ulteriori informazioni, vedere Gestione dei conflitti per i provider semplici.