Изменение отслеживания и восстановление данных
Приложения, для которых необходима синхронизация, должны учитывать возможность восстановления базы данных, для которой включено отслеживание изменений, в предыдущее состояние. Речь идет о восстановлении базы данных из резервной копии при переходе на асинхронную зеркальную базу данных или сбое при доставке журналов. Эту проблему иллюстрирует следующий сценарий.
Для таблицы Т1 включено отслеживание изменений. Минимальный действительный номер версии равен 50.
Клиентское приложение синхронизирует данные версии 100 и получает все данные отслеживания изменений, произведенных с версии 50 до версии 100.
После версии 100 в таблицу Т1 были внесены дополнительные изменения.
После создания версии 120 произошел сбой, и участник базы данных восстанавливает базу с потерей части данных. После завершения восстановления таблица содержит данные до версии 70, а минимальная синхронизированная версия по-прежнему равна 50.
Это означает, что синхронизированное хранилище данных содержит данные, которых уже нет в первичном хранилище.
Таблица Т1 обновлялась многократно. Текущий номер версии для нее — 130.
Клиентское приложение синхронизируется вновь и получает номер последней синхронизации 100. Проверка этого номера клиентом происходит успешно, так как 100 больше 50.
Клиент получает изменения между версиями 100 и 130. В этот момент времени клиент не знает, что изменения между версиями 70 и 100 уже не те, что были прежде. Данные клиента и сервера не синхронизированы.
Обратите внимание, что если бы база данных была восстановлена на момент времени после версии 100, то проблем с синхронизацией не возникло бы. Клиент и сервер должны правильно синхронизировать данные во время следующего интервала синхронизации.
Отслеживание изменений не помогает в случае необходимости восстановления утраченных данных по журналу. Однако существует две возможности обнаружения проблем синхронизации такого рода.
Сохраните идентификатор версии базы данных на сервере и обновляйте это значение при каждом восстановлении данных или их потере, вызванной любыми другими причинами. Этот идентификатор должно хранить и проверять во время синхронизации данных каждое клиентское приложение. При потере данных идентификаторы не совпадут, что заставит клиента произвести повторную инициализацию. Недостатком такого подхода является то, что клиент может проводить повторную инициализацию, которая окажется ненужной в случае, если потеря данных не пересекала границу последней синхронизации.
Когда клиент делает запрос об изменениях, сохраните номер последней версии синхронизации каждого клиента сервера. При возникновении проблем с данными номера последней синхронизированной версии не совпадут. Это будет означать, что необходима повторная инициализация.
См. также