Considerações para criar um provedor personalizado padrão
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 for necessário restaurar um repositório de dados a partir de um backup, considere os problemas a seguir.
As alterações feitas no repositório de dados após a restauração podem não ser propagadas para outras réplicas.
Isso também ocorre porque a contagem em escala usada para atribuir versões às alterações na réplica de origem podem fazer com que as alterações sejam detectadas como obsoletas. Por exemplo, um provedor de origem envia alterações para um provedor de destino. O provedor de destino aplica as alterações e atualiza o seu conhecimento. 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.
Quando o serviço de repositório de metadados é usado para armazenar metadados, a alteração da ID da réplica requer etapas adicionais. São elas:
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 causar 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 sobre conflitos de restrição, consulte Detectando e solucionando conflitos de restrição.