Ситуации, когда приходится выполнять восстановление баз из резервной копии периферийной базы (Подчиненный Узел — ПУ) распределенной информационной базы (РИБ), случаются не так уж редко. Основная проблема при этом заключается в рассинхронизации: Центральная База (ЦБ) «ушла вперед» как по данным, так и по конфигурации, а восстановленный узел содержит старые версии.
Если просто попытаться выполнить обмен, система может начать передавать огромный файл изменений конфигурации (иногда размером в несколько гигабайт), что долго и ненадежно. Кроме того, возникает вопрос потери данных, которые были созданы в промежутке между датой бэкапа и текущим моментом. Разберем подробно, как правильно восстановить работу РИБ, избежать лишнего трафика и корректно синхронизировать расширения и данные.
Первый вопрос, который возникает: как объяснить Центральной Базе, что в Подчиненном Узле конфигурация уже обновлена, и не нужно формировать огромный пакет с изменениями метаданных? Многие опасаются, что после ручного обновления периферии ЦБ все равно попытается отправить файл конфигурации.
Чтобы понять решение, углубимся в механизм работы платформы 1С. Обмен изменениями конфигурации базируется не только на номерах сообщений, но и на сверке контрольных сумм (дайджестов или хешей) конфигурации.
Алгоритм действий для исключения передачи файла конфигурации по каналам связи будет следующим:
/ResetMasterNode или программно. Однако часто достаточно просто загрузить файл конфигурации (CF), если база позволяет это сделать..cf) из актуальной Центральной Базы. Затем загружаем этот файл в восстановленную из бэкапа периферийную базу через меню «Конфигурация — Загрузить конфигурацию из файла».Самый важный момент происходит далее. Как ЦБ поймет, что конфигурации идентичны?
В заголовке каждого сообщения обмена XML содержится информация о версии конфигурации отправителя (в виде дайджеста). Когда мы обновили ПУ вручную файлом из ЦБ, их внутренние идентификаторы метаданных и дайджесты стали совпадать. Чтобы автоматизировать этот процесс в будущем, может быть полезна внешняя обработка на автоматическое обновление конфигурации, которая умеет последовательно обновлять узлы.
Когда вы сформируете сообщение обмена из Подчиненного Узла в Центральный и отправите его, ЦБ при загрузке этого сообщения проанализирует заголовок. Платформа увидит, что дайджест конфигурации ПУ совпадает с текущим дайджестом ЦБ. В результате этого действия ЦБ автоматически очистит таблицу регистрации изменений конфигурации для этого узла.
Важный вывод: Ничего страшного не произойдет. Вам не нужно вручную «ковырять» файлы обмена или таблицы SQL. Достаточно обновить ПУ файлом .cf и обязательно выполнить обмен (выгрузку из ПУ и загрузку в ЦБ).
В современных конфигурациях огромную роль играют Расширения (Extensions). Механизм РИБ поддерживает их миграцию, если у расширения установлен флаг «Используется в распределенной информационной базе».
Если вы обновите основную конфигурацию через .cf файл, но забудете про расширения, обмен не пойдет. Платформа сверяет совокупность «Основная конфигурация + Активные расширения». Если состав или версии расширений отличаются, будет ошибка проверки конфигурации, или ЦБ попытается заново выгрузить все расширения. В этом случае значительно упростить задачу поможет групповая обработка расширений базы, позволяющая быстро управлять атрибутами и состоянием расширений.
Поскольку расширений может быть много, вручную их сохранять и загружать неудобно. Для автоматизации этого процесса следует использовать параметры пакетного запуска конфигуратора.
Для выгрузки всех расширений из ЦБ используем команду:
DESIGNER /F "ПутьКБазеЦБ" /DumpConfigToFiles "ПутьКПапке" -AllExtensions
Для загрузки конкретного расширения в ПУ (если обновляем их поштучно) используем ключи /LoadCfg с указанием имени расширения:
DESIGNER /F "ПутьКБазеПУ" /LoadCfg "ПутьКФайлу.cfe" -Extension "ИмяРасширения"
Также важно помнить про идентификаторы. Если вы удалите расширение в ПУ и создадите новое с таким же именем, их внутренние ID (УИДы) будут разными, и обмен сломается. Поэтому правильный путь — именно загрузка (обновление) существующего расширения из файла .cfe, полученного из ЦБ.
После того как мы решили техническую проблему с конфигурацией, встает вопрос данных. База ПУ восстановлена из старого бэкапа. Значит, в ней не хватает данных за период «Дата Бэкапа — Текущий момент».
Многие ошибочно полагают, что ЦБ сама «догадается» выгрузить недостающее. Это не всегда так, и вот почему:
В зависимости от реализации платформы и ситуации, ЦБ может либо выдать ошибку рассинхронизации номеров, либо просто ничего не отправить, так как изменения из сообщений 91-100 уже удалены из таблицы регистрации изменений.
Как правильно действовать для восстановления данных:
Не стоит пытаться анализировать журнал регистрации или писать прямые SQL-запросы, это трудоемко и опасно. Самый надежный способ — принудительная регистрация изменений в ЦБ.
Это гарантирует, что все потерянные в ПУ данные приедут заново из ЦБ.
Еще один подводный камень — отложенные обработчики обновления. Когда вы накатываете свежую конфигурацию (через .cf) на старую базу данных (из бэкапа), версия конфигурации меняется. Платформа проверяет регистр сведений ВерсииПодсистем (в конфигурациях на БСП). Видя несоответствие, она запускает процедуры обновления данных.
Проблема в том, что:
Рекомендация:
В идеальном случае, перед первым запуском восстановленной ПУ в пользовательском режиме, стоит запустить ее с параметром, блокирующим выполнение регламентных заданий, или вручную (через обработку) скорректировать записи в регистре ВерсииПодсистем, установив там актуальные номера версий (как в ЦБ). Это заставит систему «думать», что обновление данных уже прошло. Однако делайте это только если вы уверены, что структура данных в бэкапе корректно воспринимается новой конфигурацией (обычно при минорных обновлениях это безопасно).
Для предопределенных элементов справочников (ПВХ и т.д.) в современных конфигурациях существуют механизмы авто-синхронизации, либо их можно восстановить той же обработкой регистрации изменений, выбрав конкретные объекты метаданных.
Резюмируем шаги для успешного восстановления:
.cf файл и (при необходимости) файлы расширений из ЦБ.Следуя этому плану, вы избежите траты времени на передачу гигабайтов конфигурации и гарантированно восстановите целостность данных в распределенной системе.