Consideraciones sobre el diseño de un proveedor simple personalizado
Como haría con cualquier almacén de datos de producción, debe crear con regularidad copias de seguridad de un almacén de datos involucrado en una sincronización. A la hora de restaurar un almacén de datos desde una copia de seguridad, deben tenerse en cuenta dos consideraciones principales:
Puede que los cambios efectuados en el almacén de datos después de la restauración no se propaguen a otras réplicas.
Esto puede ocurrir en un proveedor basado en delimitadores porque el delimitador que envía el proveedor de destino y que utiliza el proveedor de origen para enumerar los cambios puede encontrarse de forma lógica tras los cambios realizados después de la restauración. Por ejemplo, un proveedor basado en delimitadores envía los cambios a un proveedor de destino y este guarda el delimitador utilizado para enumerar los cambios. La réplica de origen se restaura a partir de una copia de seguridad anterior y se efectúan los cambios. La sincronización se vuelve a realizar con los mismos proveedores de origen y de destino. El proveedor de destino comienza a enviar el delimitador utilizado durante la última sincronización. En función de cómo se ha elaborado el delimitador, el proveedor de origen puede determinar que algunos de los cambios realizados tras la restauración no se deben enumerar.
Esto puede producirse también en un proveedor de enumeración completa porque el contador usado para asignar versiones a los cambios en la réplica de origen puede hacer que estos se detecten como obsoletos. Por ejemplo, un proveedor de enumeración completa envía los cambios a un proveedor de destino. El proveedor de destino aplica los cambios y actualiza su conocimiento interno. La réplica de origen se restaura a partir de una copia de seguridad anterior, lo que incluye un contador anterior. Los cambios realizados en la réplica de origen se asignan a versiones basándose en este contador anterior. Vuelve a realizarse la sincronización. Algunos de los cambios enumerados desde el proveedor de origen tienen un contador que está contenido incorrectamente en el conocimiento de destino y, de este modo, se detectan como obsoletos y no se aplican a la réplica de destino.
La solución recomendada para esta situación consiste en asignar un nuevo identificador de réplica siempre que se restaure desde una copia de seguridad. Esta solución trata la réplica restaurada como si fuera una réplica nueva que ha recibido todos sus datos desde la réplica de la copia de seguridad, al tiempo que trata la réplica de la copia de seguridad como retirada de la comunidad de sincronización. Otras réplicas de la comunidad de sincronización no tienen conocimiento de la réplica restaurada por el nuevo identificador de réplica, por lo que los nuevos elementos agregados a la réplica restaurada se envían correctamente durante la sincronización.
Los proveedores personalizados simples usan Metadata Storage Service para almacenar los metadatos, de modo que el cambio del identificador de réplica requiere los pasos siguientes.
Implementar el proveedor para que pueda operar en un modo especial diseñado para restaurarse desde una copia de seguridad. Mientras está en el modo restauración, el proveedor de destino solo aplica cambios de metadatos a la réplica de destino. El proveedor no detecta cambios locales y no aplica datos cambiados a la réplica.
Restaurar la réplica desde una copia de seguridad. Después de que la réplica se ha restaurado desde una copia de seguridad, cree dos instancias del proveedor. El proveedor de origen representa la réplica restaurada con el identificador de la réplica antigua, mientras que el proveedor de destino representa la réplica restaurada con un nuevo identificador de réplica y un nuevo almacén de metadatos. Ponga el proveedor de destino en el modo restauración.
Sincronizar desde el proveedor de origen con el proveedor de destino. Esto rellena el nuevo almacén de metadatos bajo el nuevo identificador de réplica.
Eliminar el almacén de metadatos antiguo y usar el nuevo, y un identificador de réplica nuevo, para representar la réplica. Ya está preparado para sincronizar con el resto de la comunidad de sincronización.
Los nuevos elementos creados después de la restauración pueden ocasionar colisiones entre nombres si un elemento con el mismo nombre se creó y sincronizó anteriormente. Por ejemplo, una réplica de origen almacena archivos. El proveedor de origen envía un cambio de creación para un archivo denominado "MyChange.txt". La réplica de origen se restaura a partir de una copia de seguridad anterior que no contiene MyChange.txt. Se crea un nuevo archivo MyChange.txt y el proveedor de origen le asigna un nuevo identificador de elemento. Vuelve a realizarse la sincronización. Cuando el cambio para MyChange.txt se envía, el proveedor de destino detecta un conflicto de restricción entre los dos archivos MyChange.txt, porque tienen el mismo nombre pero identificadores de elemento diferentes.
La solución recomendada a esta situación es controlar los conflictos de restricción en el proveedor. De esta manera, cuando se producen las colisiones de nombres, son informadas como conflictos de restricción y resueltas correctamente. Para obtener más información, vea Controlar conflictos en proveedores simples.