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