Резервное копирование и восстановление базы данных
Как и для любой производственной базы данных, для базы данных сервера, участвующей в синхронизации, необходимо регулярно создавать резервные копии. При восстановлении базы данных сервера из резервной копии следует учитывать два важных момента.
Изменения, произведенные в базе данных сервера после восстановления, возможно, не отразятся в базах данных клиентов или других одноранговых базах данных. Причиной этого являются значения timestamp, используемые при выборке изменений из базы данных.
Например, во время синхронизации клиента и сервера службы платформыSync Framework получают новое значение привязки от базы данных сервера и сохраняют его в клиентской базе данных. Это значение используется как верхняя граница для текущего набора синхронизируемых изменений. Дополнительные сведения см. в разделе Отслеживание изменений в базе данных сервера. После восстановления базы данных сервера значение, сохраненное в клиентской базе данных, может оказаться логически предшествующим значению, возвращенному базой данных сервера.
Клиентские или другие одноранговые базы данных, вовлеченные в синхронизацию с передачей только на сервер или двунаправленную синхронизацию, могут содержать изменения, которых нет в только что восстановленной базе данных.
В примерах этого раздела в качестве примера используется синхронизация клиента и сервера. Похожие принципы применяются к одноранговой синхронизации. Приводятся описания вопросов однорангового проектирования. Серверная база данных является удаленным одноранговым узлом. Клиентская база данных сервера является локальным одноранговым узлом. Дополнительные сведения о создании резервной копии и восстановлении баз данных SQL Server, синхронизация которых выполняется с помощью SqlSyncProvider, см. в разделе Как выполнить резервное копирование и восстановление базы данных (SQL Server).
Серверная база данных
Чтобы понять, как клиентская база данных может оказаться логически впереди серверной базы данных, рассмотрите способ отслеживания обновлений в таблице Sales.Customer образца базы данных, прилагаемого к платформам Sync Framework. В столбце UpdateTimestamp хранится значение типа timestamp, а команда для новой привязки возвращает значение функции SQL Server MIN_ACTIVE_ROWVERSION. Для ясности в примере приведены целочисленные значения вместо шестнадцатеричных.
Перед восстановлением базы данных MIN_ACTIVE_ROWVERSION возвращает значение 31. Это значение сохраняется в клиентской базе данных как последнее полученное значение привязки.
После восстановления базы данных функция MIN_ACTIVE_ROWVERSION возвращает значение 19.
В результате выполнения операций обновления значение timestamp в столбце UpdateTimestamp становится равным 32.
Выполняется синхронизация, и функция MIN_ACTIVE_ROWVERSION возвращает значение 32. В таблицу Sales.Customer загружается последнее обновление, поскольку значение 32 больше последнего полученного значения привязки 31. Обновления между значениями 19 и 31 не распознаны как изменения.
Эта проблема может возникнуть в любой схеме отслеживания, использующей логическое измерение времени — например, отметки времени. В схемах отслеживания на основе даты и времени такая проблема не возникает, поскольку часы идут вперед независимо от состояния базы данных. При одноранговой синхронизации для отслеживания изменений требуется отметка времени.
Для решения проблемы, связанной с отметками времени, используется один из следующих способов.
Присвойте отметке времени сервера значение, которое у нее было до операции восстановления. В приведенном выше примере можно выполнять фиктивные обновления в отдельной таблице, пока функция MIN_ACTIVE_ROWVERSION не возвратит значение 31.
Мы рекомендуем следующий подход к одноранговой синхронизации.
Храните точки привязки для каждого клиента на сервере. В предыдущем примере последней полученной точкой привязки от резервной копии было 19. Поэтому будут распознаны все последующие обновления, то есть будут загружены все изменения в диапазоне значений от 19 до 32. Службы Sync Framework не обеспечивают для этого встроенной поддержки, но система может быть создана на сервере следующим образом.
В базе данных сервера создайте таблицу, имеющую по одной строке для каждого из клиентов. Таблица должна включать столбец идентификаторов, которые службы Sync Framework создают для каждого клиента, и столбец со значениями привязки для этого клиента. Во время синхронизации приложение обновляет этот столбец новым значением привязки.
Измените команды синхронизации таким образом, чтобы они выбирали наименьшее значение привязки для синхронизируемого клиента. Это значение может храниться как в базе данных клиента, так и в клиентской базе данных. После операции восстановления базы данных значение в базе данных сервера будет меньше, чем в клиентской базе данных. Если произошла ошибка после записи значения в таблицу сервера, то, перед тем как произошло применение изменений на клиенте, значение в клиентской базе данных будет меньше, чем в базе данных сервера. Если синхронизация прошла нормально, эти значения будут равны. Команда вставки может быть определена следующим образом.
SELECT CustomerId, CustomerName, SalesPerson, CustomerType FROM Sales.Customer WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id) OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor AND InsertId <> @sync_client_id
Клиентские базы данных
После восстановления базы данных сервера на текущий момент времени с учетом метаданных синхронизации в ней по-прежнему отсутствуют изменения, выполненные на клиентах с момента создания резервной копии. Чтобы клиент реагировал соответствующим образом, он должен знать о том, что база данных сервера была восстановлена. Для этого можно использовать таблицу отслеживания на стороне сервера, которая указывает, производилось ли восстановление с момента последней синхронизации конкретного клиента. Во время каждого сеанса синхронизации клиентское приложение первым делом проверяет эту таблицу, чтобы определить, можно ли синхронизироваться нормальным образом или необходимо выполнить специальный код для работы с восстановленной базой данных.
Когда клиентское приложение определяет, что база данных сервера была восстановлена, приложение может осуществить совмещение клиентской и серверной баз данных. Сделать это можно несколькими способами, включая следующие подходы.
Повторно инициализировать клиентскую базу данных, удалив все таблицы, после чего синхронизироваться с сервером. Это самый простой подход, но все изменения на клиенте будут потеряны.
Повторная инициализация — рекомендуемый подход к одноранговой синхронизации. Сведения об инициализации одноранговых БД см. в разделе «Инициализация базы данных сервера» документа Как настроить и выполнить синхронизацию совместной работы (не SQL Server).
Повторно инициализировать клиентскую базу данных после создания копии клиентских таблиц. Приложение может выполнить следующие шаги.
Обнаружить, что база данных сервера была восстановлена.
Создать копии всех таблиц клиентской базы данных, после чего удалить оригинальные таблицы.
Синхронизироваться с сервером для загрузки новой схемы и новых данных.
Сравнить строки в новых таблицах с созданными копиями.
Обнаружить все различия между двумя наборами таблиц и применить к новым таблицам все необходимые изменения.
Синхронизироваться вновь, чтобы передать на сервер изменения, примененные к новым таблицам.