Consideraciones sobre el diseño de un proveedor personalizado estándar
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. Si tiene que restaurar un almacén de datos desde una copia de seguridad, considere las cuestiones siguientes.
Puede que los cambios que se efectuaron en el almacén de datos después de la restauración no se propaguen a otras réplicas.
Esto puede producirse 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 origen envía los cambios a un proveedor de destino. El proveedor de destino aplica los cambios y actualiza su conocimiento. 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.
Cuando se usa Metadata Storage Service para almacenar metadatos, el cambio del identificador de réplica requiere pasos adicionales. Estos son:
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 sobre conflictos de restricción, vea Detectar y resolver conflictos de restricción.