Ошибки в распределенных информационных базах (РИБ) — одна из наиболее сложных задач для администратора 1С. Ситуация, когда конфигурация периферийного узла (ПБ) перестает соответствовать ожидаемой в центральной базе (ЦБ), блокирует передачу данных и может привести к накоплению огромных файлов обмена, исчисляемых гигабайтами. В этой статье мы подробно разберем, как восстановить работоспособность обмена, разберемся в причинах сбоя и научимся управлять счетчиками сообщений.
Прежде чем приступать к активным действиям, важно понять механику возникновения ошибки «Конфигурация узла распределенной ИБ не соответствует ожидаемой». В штатном режиме изменения метаданных передаются из Центральной базы в Периферийную внутри XML-файла обмена. Платформа 1С при чтении такого файла сначала обновляет структуру базы данных ПБ и только потом загружает сами данные.
Рассмотрим основные причины, по которым этот механизм дает сбой:
Проанализируем ситуацию, когда обмен отсутствует длительное время (например, несколько недель). За это время файл обмена может вырасти до критических размеров (1.5 Гб и более), так как система регистрирует каждое изменение объекта и пытается передать его снова и снова при каждой неудачной попытке.
Первым делом нам необходимо получить эталонную конфигурацию из центрального узла. Для этого выполним следующие действия в Центральной базе:
central_base.cf).Этот файл послужит нам «лекарством» для периферийного узла, который потерял синхронность.
Поскольку обычный обмен не может загрузить изменения, нам придется «отвязать» периферийную базу от центральной, обновить ее вручную и «привязать» обратно. Разберем этот процесс по шагам.
Важно: Все манипуляции в периферийной базе необходимо проводить в монопольном режиме, предварительно создав резервную копию.
Для начала нам нужно программно снять признак того, что база является подчиненным узлом. В конфигураторе это сделать невозможно, поэтому воспользуемся встроенным языком 1С. Создадим внешнюю обработку или воспользуемся консолью кода:
// Снимаем привязку к главному узлу
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого кода база станет «автономной». Теперь мы можем внести изменения в ее структуру:
central_base.cf, полученный из ЦБ.Теперь структура базы идентична центральной. Нам нужно вернуть статус подчиненного узла. Выполним следующий код, где СсылкаНаЦентральныйУзел — это элемент плана обмена, соответствующий головной базе:
// Устанавливаем главный узел обратно
Центр = ПланыОбмена.Полный.НайтиПоКоду("ЦБ"); // Замените "ЦБ" на ваш код центрального узла
ПланыОбмена.УстановитьГлавныйУзел(Центр);
После восстановления структуры базы обмен может не пойти из-за ошибки: «Номер сообщения меньше или равен ранее принятому». Это происходит потому, что в каждой базе хранятся два числа: «Номер принятого» и «Номер отправленного».
Рассмотрим, как работают счетчики:
Если счетчики разошлись более чем на 20 единиц, как в рассматриваемом случае, их нужно скорректировать вручную. Зайдите в План обмена (через «Все функции» или интерфейс программы), откройте карточку соответствующего узла и проверьте поля «Номер принятого» и «Номер отправленного».
Практический совет: Если вы не уверены, какие номера ставить, можно обнулить счетчики на обеих сторонах. Однако помните, что после обнуления система может попытаться выгрузить большой объем данных. Если базы уже идентичны, лучше установить номера вручную так, чтобы номер отправленного в одной базе был на 1 больше номера принятого в другой.
Файл размером 1.5 Гб крайне сложно передать через медленные каналы связи (например, OpenVPN). Выясним причину такого объема: это накопленная регистрация изменений объектов.
Чтобы уменьшить файл, выполним следующие действия в Центральной базе:
Рассмотрим ситуацию, когда регистрацию снимать нельзя. В этом случае рекомендуем:
Проанализируем ошибку из примера: Поле объекта не обнаружено (_Организации). Это классический признак того, что конфигурация базы данных не была обновлена до конца. Вы загрузили .cf файл, но не нажали «Обновить конфигурацию базы данных» (F7) или процедура реорганизации была прервана. В результате программный код пытается обратиться к полю в таблице SQL, которой еще физически не существует. Всегда дожидайтесь завершения процесса реорганизации, когда 1С выводит список измененных объектов.
Также помните, что при сравнении конфигураций отчет может показывать изменения в порядке объектов. Это не всегда критично для работы, но при полной загрузке .cf файла такие различия нивелируются.
Использование описанного алгоритма — отвязка узла, полная загрузка конфигурации и восстановление связи — является наиболее надежным способом реанимации РИБ без необходимости пересоздания начального образа, что особенно важно для баз с большим объемом данных и работающими пользователями.