Рекомендации по разработке стандартного пользовательского поставщика
Как и для любого производственного хранилища данных, для хранилища данных, участвующего в синхронизации, необходимо регулярное создание резервных копий. При восстановлении хранилища данных сервера из резервной копии следует учитывать несколько важных моментов.
Возможно, что изменения, выполненные в хранилище данных после восстановления, не отразятся в других репликах.
Присваивание счетчика пакетов в качестве версий изменений на исходной реплике приведет к тому, что такие изменения будут опознаны как устаревшие. Например, поставщик источника отправляет изменения на поставщик назначения. Поставщик назначения применяет изменения и обновляет свои наборы знаний. Исходная реплика восстанавливается из более ранней резервной копии, в которой установлен счетчик пакетов, соответствующий моменту ее создания. Изменениям, сделанным на исходной реплике, присваиваются версии на основе старого счетчика пакетов. Синхронизация выполняется еще раз. Некоторые из изменений, перечисленных с поставщика источника, будут иметь счетчик пакетов, ошибочно совпадающий с содержащимся в наборе знаний назначения. Поэтому они определятся как устаревшие и не будут применены к конечной реплике.
Рекомендуемое решение данной проблемы заключается в присвоении нового идентификатора реплике всякий раз после ее восстановления из резервной копии. В этом случае восстановленная реплика считается новой, получившей все данные из резервной копии. Новая реплика рассматривает реплику резервной копии как выведенную из сообщества синхронизации. Остальные реплики в сообществе синхронизации не имеют набора знаний восстановленной реплики, поскольку эта реплика имеет новый идентификатор. Таким образом, все новые элементы, добавленные в восстановленную реплику, правильно отправляются во время синхронизации.
Если служба хранилища метаданных используется для хранения метаданных, то изменение идентификатора реплики требует выполнения дополнительных шагов. А именно:
Реализуйте поставщик, работающий в особом режиме, подходящем для восстановления из резервной копии. В режиме восстановления поставщик назначения применяет к конечной реплике только изменения метаданных. Поставщик не обнаруживает локальные изменения и не применяет данные изменений к реплике.
Восстановите реплику из резервной копии. После восстановления реплики из резервной копии создайте два экземпляра поставщика. Поставщик источника представляет восстановленную реплику с прежним идентификатором, а поставщик назначения — восстановленную реплику с новым идентификатором и новым хранилищем метаданных. Переведите поставщик назначения в режим восстановления.
Выполните синхронизацию из поставщика источника в поставщик назначения. Это позволит заполнить новое хранилище метаданных c новым идентификатором реплики.
Удалите старое хранилище метаданных и используйте новое хранилище и новый идентификатор реплики для ее представления. Теперь можно выполнить синхронизацию для остального сообщества синхронизации.
Новые элементы, созданные после восстановления, могут вызвать конфликты совпадения имен, если элемент с таким именем уже ранее был создан и синхронизирован.
Например, в исходной реплике хранятся файлы. Поставщик источника отправляет изменение создания для файла MyChange.txt. Исходная реплика восстанавливается из более ранней резервной копии, в которой нет файла MyChange.txt. Создается новый файл MyChange.txt, которому поставщик источника присваивает новый идентификатор элемента. Синхронизация выполняется еще раз. При отправке изменения для файла MyChange.txt поставщик назначения обнаруживает конфликт ограничения между двумя файлами MyChange.txt, поскольку они имеют одно и то же имя, но разные идентификаторы.
Рекомендуемым решением является разрешение конфликтов ограничений в поставщике. В этом случае при возникновении конфликтов имен они будут рассматриваться как конфликты ограничений и правильно разрешаться. Дополнительные сведения о конфликтах ограничений см. в разделе Обнаружение и разрешение конфликтов ограничений.