Considerações para criar um provedor personalizado simples
Como em qualquer repositório de dados de produção, deve-se fazer backup regularmente de um repositório de dados envolvido em operações de sincronização. Se você tiver que restaurar um repositório de dados a partir de um backup, há duas considerações principais:
As alterações feitas no repositório de dados após a restauração podem não ser propagadas para outras réplicas.
Isso pode ocorrer em um provedor baseado em âncora, pois a âncora enviada pelo provedor de destino que o provedor de origem usa para enumerar as alterações pode estar logicamente depois das alterações feitas após a restauração. Por exemplo, um provedor baseado em âncora envia alterações para um provedor de destino, que salva a âncora usada para enumerar as alterações. A réplica de origem é restaurada de um backup anterior e as alterações são realizadas. A sincronização é executada novamente com os mesmos provedores de origem e destino. O provedor de destino começa enviando a âncora usada durante a última sincronização. Dependendo de como a âncora foi construída, o provedor de origem pode detectar que algumas das alterações feitas após a restauração não deveriam ser enumeradas.
Isso também pode ocorrer em um provedor de enumeração completa, pois a contagem em escala usada para atribuir versões às alterações na réplica de origem podem fazer com que alterações sejam detectadas como obsoletas. Por exemplo, um provedor de enumeração completa envia alterações a um provedor de destino. O provedor de destino aplica as alterações e atualiza seu conhecimento interno. A réplica de origem é restaurada de um backup anterior, que inclui uma contagem em escala anterior. As alterações feitas na réplica de origem são versões atribuídas com base nessa contagem em escala anterior. A sincronização é executada novamente. Algumas das alterações enumeradas do provedor de origem possuem uma contagem em escala contida incorretamente no conhecimento de destino, sendo assim, são detectadas como obsoletas e não são aplicadas à réplica de destino.
A solução recomendada para essa situação é atribuir uma nova ID de réplica a uma réplica sempre que ela for restaurada de um backup. Assim, as réplicas restauradas são tratadas como se fossem uma nova réplica que recebeu todos os seus dados da réplica da qual foi feito o backup, e a réplica da qual foi feito o backup é tratada como aposentada da comunidade de sincronização. Outras réplicas na comunidade de sincronização não têm conhecimento da réplica restaurada devido à nova ID de réplica, assim, novos itens adicionados à réplica restaurada são enviados corretamente durante a sincronização.
Provedores personalizados simples usam o serviço de armazenamento de metadados para armazenar metadados, assim, alterar a ID da réplica exige as etapas a seguir.
Implemente o provedor para que ele possa operar de um modo especial criado para a restauração de um backup. No modo de restauração, o provedor de destino só aplica alterações de metadados à réplica de destino. O provedor não detecta alterações locais e não aplica dados de alteração à réplica.
Restaure a réplica do backup. Depois que a réplica for restaurada de um backup, crie duas instâncias do provedor. O provedor de origem representa a réplica restaurada com a ID de réplica antiga e o provedor de destino representa a réplica restaurada com uma nova ID de réplica e um novo repositório de dados. Coloque o provedor de destino em modo de restauração.
Sincronize do provedor de origem ao provedor de destino. Isso popula o novo repositório de metadados sob a nova ID de réplica.
Exclua o antigo repositório de dados e use o novo repositório de dados e a nova ID de réplica para representar a réplica. Agora você está pronto para sincronizar com o resto da comunidade de sincronização.
Novos itens criados após a restauração podem causam colisões de nomes quando um item com o mesmo nome já tiver sido criado e sincronizado anteriormente. Por exemplo, uma réplica de origem armazena arquivos. O provedor de origem envia uma alteração de criação para um arquivo denominado "MyChange.txt". A réplica de origem é restaurada de um backup anterior que não contém MyChange.txt. Um novo arquivo MyChange.txt é criado e é designado com uma nova ID de item pelo provedor de origem. A sincronização é executada novamente. Quando a alteração para MyChange.txt for enviada, o provedor de destino detectará um conflito de restrição entre os dois arquivos MyChange.txt, pois os dois possuem o mesmo nome mas IDs de item diferentes.
A solução recomendada para essa situação é tratar conflitos de restrição no provedor. Desse modo, quando ocorrerem colisões de nome, elas serão relatadas como conflitos de restrição e serão resolvidas corretamente. Para obter mais informações, consulte Resolvendo conflitos para provedores simples.