Замена клиентских синхронизирующих баз данных - PullRequest
Новая
       4

Замена клиентских синхронизирующих баз данных

0 голосов
/ 02 августа 2011

Мы как бы стреляли в ногу на клиентском сайте в отношении Microsoft Sync Framework при устранении неполадок в конкретной производственной проблеме ...

В качестве системы записи данных у нас есть центральный сервер, который предоставляет службу WCF, через которую мы используем Sync Framework 2.0 для синхронизации данных с отключенными клиентскими экземплярами. (Многие детали реализации неизвестны, это унаследованная кодовая база.) При устранении проблемы на компьютере пользователя в какой-то момент в прошлом было принято решение стереть локальную базу данных конкретного клиента и заменить ее известной хорошая копия с другого клиента.

Все , казалось, какое-то время работало. Но в реализации была одна деталь, которая была нам неизвестна в то время. Внутренняя синхронизация отслеживает идентичность клиентской базы данных. Это означало, что сервер не мог различить двух клиентов. Таким образом, один будет синхронизировать их данные, а другой останется в неизвестном состоянии.

Мы определили затронутых пользователей, мы идентифицируем затронутые данные и проводим мозговой штурм потенциальных решений. В этой последней части мне интересно, есть ли у кого-нибудь здесь какой-либо опыт работы с Sync Framework и может ли он предложить потенциальный курс действий?

Один из возможных подходов, который мы рассматриваем, заключается в том, чтобы определить, где и как Sync внутренне отслеживает эту идентификацию (возможно, GUID где-нибудь?) И изменять ее. Это похоже на самое быстрое исправление, хотя, по крайней мере, у нас по-прежнему не будет необходимости снова касаться затронутых записей, чтобы снова запустить их синхронизацию.

Мы не хотим рисковать потерей данных, поэтому не решаемся отбросить клиентские базы данных и повторно предоставить их. Но более важно то, что процесс подготовки новой базы данных является значительным ударом по ресурсам и простоям пользователей в текущей настройке, поэтому по возможности этого следует избегать.

Кто-нибудь здесь имеет опыт работы с Sync Framework? Кто-нибудь сталкивался с этой проблемой раньше? Какие пути подхода вы бы предложили?

Ответы [ 2 ]

1 голос
/ 02 августа 2011

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

  • Какой «поставщик синхронизации» используется?БД / Файл / Пользовательский?
  • Какие реализованы / настраиваются «правила разрешения конфликтов»?
  • Какая версия фреймворка?2.0 или 2.1?

РЕДАКТИРОВАТЬ - согласно комментариям:

Я не уверен на 100% - пожалуйста, передайте это сначала одному клиенту и проверьте результаты! Сначала замените GUID клиента на клиенте, который случайно получил копию другого клиента (в противном случае "правильно работающий" испорчен!).Затем позвоните PerformPostRestoreFixup для этого клиента db.для более подробной информации см.http://msdn.microsoft.com/en-us/library/ee617375.aspx
http://msdn.microsoft.com/en-us/library/bb726041.aspx

0 голосов
/ 03 августа 2011

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

Если ваши клиенты используют SqlServer или SqlExpress, вы можете запустить PerformPostRestoreFixup, и Sync Framework настроит для вас Id клиента и карту ключей реплики.

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

В вашем случае, когда клиенты потенциально уже не синхронизированы, вам может потребоваться выполнить некоторую проверку после PerformPostRestoreFixup

...