Considerazioni relative alla progettazione di provider personalizzati standard
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, considerare gli aspetti seguenti.
Le modifiche apportate nell'archivio dati dopo il ripristino potrebbero non venire propagate ad altre repliche.
Questa situazione può verificarsi 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 origine invia modifiche a un provider di destinazione. Il provider di destinazione applica le modifiche e aggiorna la propria conoscenza. 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.
Quando per archiviare i metadati si utilizza il servizio di archiviazione dei metadati, la modifica dell'ID replica richiede l'esecuzione di passaggi aggiuntivi, ovvero:
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 sui conflitti di vincoli, vedere Rilevamento e risoluzione dei conflitti di vincoli.