фреймворк синхронизации по сценариям резервного копирования / восстановления

Я синхронизирую базы данных SQL Server с помощью Microsoft Sync Framework.

Мои базы данных часто восстанавливаются до более ранних версий, и мне нужно постоянно обновлять отца (место назначения процесса синхронизации).

Дело в том, что у меня есть ребенок A со столом T1 и отец B со столом T1.

Обе таблицы T1 имеют таблицу, которая «записывает» операции, называемая T1_tracking. Сначала я синхронизирую T1 от A до B. Затем я восстанавливаю базу данных в A до более ранней версии и снова генерирую данные, хранящиеся в T1 (с другой информацией). Следовательно, T1_tracking в A полностью отличается от T1_tracking в B, и Sync Framework говорит мне, что он не имеет ничего общего.

Любое решение? Пожалуйста спасибо!!...


person user4227199    schedule 11.12.2014    source источник


Ответы (1)


вам необходимо запустить PerformPostRestoreFixup после восстановления базы данных и перед ее синхронизацией.

у областей есть реплика, которая идентифицирует каждую реплику. если вы восстановите базу данных, у вас будет две области с одинаковым идентификатором, что приведет к тому, что данные не будут синхронизироваться.

для иллюстрации, предположим, что T1 был синхронизирован с A, а A записывает, что последний раз, когда он синхронизировался с T1, имеет отметку времени 1000.

затем вы восстанавливаете A до более старой версии, которая, конечно, имеет меньшие значения меток времени. вы обновляете данные на восстановленной базе данных, но метка времени достигает только, скажем, 700.

когда вы синхронизируете его с T1, T1 говорит, что дайте мне изменения с отметкой времени больше 1000 (отметка времени, записанная при последней синхронизации). так что никаких изменений не обнаружено.

Sync FX выполняет инкрементную синхронизацию, например, что изменилось с момента последней синхронизации. он не сравнивает строку за строкой, чтобы проверить различия между таблицами.

запустив PerformPostRestoreFixup, вы дадите восстановленной копии новый идентификатор реплики. Старый репликационный идентификатор все еще отслеживается в T1, поэтому он знает, что уже синхронизировал существующие данные в восстановленной базе данных. однако новые изменения будут отражены в новом реплике, поэтому, когда он синхронизируется, T1 не знает об этом (у него нет записи с отметкой времени, когда он в последний раз синхронизировался с новым реплицированным идентификатором) и, таким образом, сможет обнаруживать изменения для синхронизации.

P.S., это упрощенная иллюстрация вашего сценария, есть еще кое-что, что происходит под капотом.

person JuneT    schedule 13.12.2014