В процессе сопровождения распределенных информационных баз (РИБ) разработчики и администраторы нередко сталкиваются с ситуацией, когда данные между базами курсируют без ошибок, однако доработанная в центре конфигурация упорно не применяется на периферии. При этом монитор обмена может бодро сообщать об успешном завершении сеанса, а размер файла обмена наглядно свидетельствует о наличии внутри дельты метаданных. Разберем механику этой проблемы, выясним истинные причины такого поведения платформы и пошагово рассмотрим способы восстановления штатной работы распределенной системы.
Анализ номеров сообщений: что означают счетчики обмена
Когда обмен данными останавливается, первое, на что обращают внимание специалисты, — это номера пакетов в заголовках XML-файлов. Проанализируем типичный пример из практики:
Пакет из подчиненного узла в главный:
<v8msg:MessageNo>15</v8msg:MessageNo>
<v8msg:ReceivedNo>21</v8msg:ReceivedNo>
Пакет из главного узла в подчиненный:
<v8msg:MessageNo>22</v8msg:MessageNo>
<v8msg:ReceivedNo>15</v8msg:ReceivedNo>
Многие ошибочно полагают, что такое расхождение счетчиков является признаком рассинхронизации. Однако это совершенно нормальная картина протокола 1С:Предприятие. Посмотрим внимательно на эти значения:
Номер исходящего сообщения (MessageNo) увеличивается на единицу при каждой новой выгрузке из узла-отправителя.
Номер принятого сообщения (ReceivedNo) фиксирует номер пакета, который база успешно смогла прочитать и применить в прошлый раз.
Значение ReceivedNo = 21 в периферийной базе показывает, что она уже приняла 21-й пакет от центра. В то же время центр сформировал новый пакет MessageNo = 22, но периферия его еще не прочитала.
Пакет под номером 22 был отправлен, но периферийный узел по какой-то причине не смог завершить процедуру его разбора. Соответственно, сброс номеров сообщений с помощью обработки Регистрация изменений для обмена в подобном случае устраняет лишь симптом, но не ликвидирует корень проблемы.
Почему подчиненный узел игнорирует обновление конфигурации
Выясним основные технические причины, препятствующие автоматическому применению структуры метаданных:
Блокировка сеансами или запущенным Конфигуратором. Если в подчиненном узле кто-то запустил сеанс в режиме Конфигуратор или в базе активны незавершенные пользовательские и фоновые сеансы, платформа не сможет монопольно заблокировать таблицы метаданных для их реструктуризации.
Отсутствие команды обновления конфигурации базы данных. Платформа может корректно прочитать дельту метаданных из XML-пакета и загрузить ее в основную конфигурацию, но при этом обновление конфигурации базы данных (динамическое или полное) не происходит автоматически из-за настроек сценария или прав учетной записи, под которой запускается регламентное задание.
Скрытые ошибки сериализации. Если в главном узле применялось так называемое динамическое обновление, внутреннее состояние версий метаданных может нарушиться. Главный узел выгружает изменения, но на стороне дочернего узла при попытке их сопоставления возникает некритичное системное исключение, которое подавляется стандартными обработчиками обмена.
Поиск скрытых ошибок в журнале регистрации
Если монитор обмена сообщает об успехе, но метаданные не обновились, не следует полагаться на встроенные типовые отборы в режиме 1С:Предприятие. Разберем, как правильно найти реальную причину сбоя:
Откроем Журнал регистрации непосредственно в режиме Конфигуратор в проблемной периферийной базе.
Снимем любые предустановленные фильтры по подсистеме обмена данными или конкретным метаданным. Зачастую ошибка падения фонового процесса записи конфигурации БД регистрируется без привязки к плану обмена.
Установим интервал времени строго вокруг момента выполнения обмена данными (за 2–3 минуты до начала и после окончания сеанса).
Изучим системные события уровня Ошибка и Предупреждение. Особое внимание обратим на записи с событиями транзакций, блокировок таблиц и ошибок блокировки монопольного режима.
Способ 1. Принудительное обновление конфигурации базы данных
Нередко изменение конфигурации уже получено и находится в подвешенном состоянии. Проверим эту гипотезу:
Завершим все сеансы пользователей в периферийной информационной базе.
Запустим режим Конфигуратор под пользователем с полными административными правами.
Обратим внимание на пиктограмму сохранения или пункт меню Конфигурация — Обновить конфигурацию базы данных (горячая клавиша F7). Если пункт активен или подсвечен синим восклицательным знаком, значит, файл метаданных был успешно принят из центра, но база данных еще не перестроилась под новую структуру.
Выполним обновление структуры и применим изменения.
Способ 2. Принудительное переформирование пакета метаданных в центре
Если файл не содержит корректного пакета изменений метаданных из-за сбоя версионирования в центре, выполним принудительную перерегистрацию конфигурации:
В центральной информационной базе откроем Конфигуратор.
Внесем любое незначительное изменение, не влияющее на данные (например, отредактируем комментарий у любой общей подсистемы или реквизита).
Выполним полноценное обновление конфигурации базы данных монопольно (без использования динамического обновления). Это действие принудительно обновит внутренний номер версии конфигурации.
Запустим сеанс выгрузки обмена из центра. В результате сформируется файл, гарантированно содержащий полную секцию метаданных.
Способ 3. Восстановление синхронизации через прямое обновление конфигурации
Если платформа в узле РИБ категорически отказывается принимать структуру метаданных через XML-сообщение, применим надежный метод выравнивания через отвязку узла. Разберем этот регламент по шагам:
В центральной базе перейдем в меню Конфигурация — Сохранить конфигурацию в файл... и получим актуальный файл .cf.
В периферийной базе создадим резервную копию и откроем внешнюю обработку или обработку с произвольным кодом. Снимем признак подчинения узла главному, выполнив код:ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Перезапустим подчиненную базу в режиме Конфигуратор. База станет независимой, и меню редактирования конфигурации разблокируется.
Через меню Конфигурация — Загрузить конфигурацию из файла... накатим ранее сохраненный .cf файл из центральной базы и обновим конфигурацию базы данных (клавиша F7). На этом этапе конфигурации центра и периферии станут абсолютно идентичными на бинарном уровне.
Вернем периферийной базе статус подчиненного узла РИБ, выполнив команду:
Теперь выполним повторный обмен данными. Поскольку конфигурации полностью совпадают, пакет обмена примет только накопленные данные документов и справочников, а механизм РИБ продолжит штатное функционирование без постоянных сбросов счетчиков.