Как правильно добавить третий узел в распределенную информационную базу 1С:УТ 11 и устранить ошибки синхронизации?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При масштабировании распределенной информационной базы (РИБ) на базе конфигурации «1С:Управление торговлей 11» стандартная процедура создания нового филиала часто вызывает затруднения. Попытка просто скопировать центральную базу и указать ее в качестве периферийной приводит к ошибкам неуникальности кодов планов обмена, конфликтам блокировок при формировании начального образа и проблемам с регистрацией изменений. Разберем детально, как правильно подключить третий узел к работающей связке, какие методы платформы 1С для этого применить и как решить сопутствующие сбои обмена данными.

Способ 1. Создание периферийной базы через начальный образ (штатный метод)

Рассмотрим классический вариант создания нового подчиненного узла средствами платформы 1С:Предприятие. Данный путь гарантирует целостность служебных таблиц и таблиц регистрации изменений, однако требует значительных ресурсов сервера.

  1. В центральной информационной базе (ЦБ) перейдем в раздел администрирования или регламентированного учета к настройкам синхронизации данных.
  2. Создадим новую настройку для распределенной информационной базы с указанием уникального кода (например, У2 или ПБ2) и наименования нового узла.
  3. Настроим транспорт сообщений (каталог обмена на сетевом диске или FTP-сервер).
  4. Запустим процедуру «Создание начального образа информационной базы».

Обратите внимание на ограничения: процедура СоздатьНачальныйОбраз накладывает монопольные и разделяемые блокировки на таблицы метаданных. В рабочей базе с активными пользователями это неизбежно провоцирует ошибку «Конфликт блокировок при выполнении транзакции», а также может нарушить работу параллельных обменов (например, с «1С:Бухгалтерией предприятия»). Рекомендуем формировать начальный образ во внерабочее время, предварительно заблокировав регламентные задания и сеансы пользователей, либо выгружать образ из актуальной копии центральной базы на тестовом сервере.

Способ 2. Быстрое развертывание узла из копии центральной базы

Если объем информационной базы велик и создание начального образа штатным мастером занимает слишком много времени или аварийно прерывается, применим ускоренный инженерный подход. Мы можем развернуть копию центральной базы и программно перенастроить ее в подчиненный узел. Проанализируем этот алгоритм по шагам.

  1. В центральной базе заблаговременно создадим новый узел плана обмена. Например, в плане обмена будут узлы: ЦБ (текущий/главный), ПБ1 (существующая периферия) и ПБ2 (новый узел).
  2. Сделаем резервную копию центральной базы и развернем ее на сервере нового узла.
  3. Очистим регистрацию изменений в созданной копии. Так как база получена из рабочей ЦБ, в ней накоплена регистрация сотен тысяч объектов, которые при первом запуске попытаются выгрузиться обратно. Выполним в копии следующий код:
    
    ВыборкаУзлов = ПланыОбмена.Полный.Выбрать();
    Пока ВыборкаУзлов.Следующий() Цикл
        УзелОбъект = ВыборкаУзлов.ПолучитьОбъект();
        ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбъект.Ссылка);
    КонецЦикла;
    
  4. Удалим в копии базы узел ПБ1, так как периферийные базы в топологии «звезда» никогда не взаимодействуют напрямую друг с другом. Обмен должен идти исключительно по схеме «Центр — Периферия».
  5. Переименуем коды узлов. Платформа контролирует уникальность кода узла в пределах одного плана обмена, поэтому поменять коды ЦБ и ПБ2 напрямую не удастся — возникнет ошибка проверки уникальности. Выполним подмену через промежуточный код: сначала зададим узлу ЦБ временный код TEMP, затем узлу ПБ2 присвоим код ЦБ, а узлу TEMP назначим код периферийного узла ПБ2. Предопределенный узел «ЭтотУзел» в копии должен получить код новой периферии (ПБ2).
  6. Назначим узел ЦБ главным для текущей базы. Для этого выполним встроенный метод платформы:
    
    СсылкаНаГлавный = ПланыОбмена.Полный.НайтиПоКоду("ЦБ");
    Если ЗначениеЗаполнено(СсылкаНаГлавный) Тогда
        ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавный);
    КонецЕсли;
    
  7. Для корректной инициализации параметров Библиотеки стандартных подсистем (БСП) и сопоставления идентификаторов метаданных выполним первый запуск новой базы через командную строку с ключом /C ЗапуститьОбновлениеИнформационнойБазы.

Решение проблемы: «Номер сообщения меньше либо равен ранее принятому»

Выясним причину этой распространенной ошибки. При передаче пакетов обмена РИБ в заголовке XML-файла указываются номера отправленного и принятого сообщений. Если счетчики в узлах рассинхронизировались, платформа блокирует чтение пакета для защиты от потери данных. Чтобы сбросить счетчики номеров сообщений в исходное состояние, откроем свойства узлов в плане обмена через встроенную обработку или выполним код в обеих базах для соответствующего узла-корреспондента:


УзелОбъект = ПланыОбмена.Полный.НайтиПоКоду("КодУзла").ПолучитьОбъект();
УзелОбъект.НомерПринятого = 0;
УзелОбъект.НомерОтправленного = 0;
УзелОбъект.Записать();

Как передать документы за определенный период и избежать задвоений?

Механизм РИБ не имеет встроенного фильтра по периодам — он передает любые объекты, зафиксированные в таблицах регистрации изменений. Если в новую периферийную базу не попали документы за предыдущие дни, воспользуемся штатной обработкой РегистрацияИзмененийДляОбмена:

  1. Откроем обработку в базе-источнике (через меню «Все функции» или функции для технического специалиста).
  2. Выберем целевой узел обмена.
  3. Найдем нужные документы и нажмем «Зарегистрировать изменения с отбором», указав требуемый интервал дат.
  4. Обязательно установим флаг «Выгружать движения с документами», чтобы вместе с документами в узел транслировались проводки и записи регистров накопления.

Устранение ошибки: «Конфигурация ИБ не соответствует ожидаемой»

Рассмотрим ситуацию, когда центральная база выгружает сообщение с изменениями структуры конфигурации, а периферийная база при регламентном фоновом задании не может его применить. Часто это происходит из-за динамического обновления («демонического обновления») в центральном узле, из-за которого внутренние идентификаторы версии конфигурации БД расходятся. Решим проблему методом прямого обновления через файл конфигурации (.cf):

  1. В центральной базе через конфигуратор выгрузим конфигурацию в файл: «Конфигурация» — «Сохранить конфигурацию в файл» (.cf).
  2. В периферийной базе временно снимем признак подчиненности главному узлу программным вызовом: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
  3. Запустим конфигуратор периферийной базы и загрузим полученный файл (пункт меню «Конфигурация» — «Загрузить конфигурацию из файла» или «Сравнить, объединить с конфигурацией из файла»). Нажмем F7 для обновления конфигурации базы данных.
  4. Важный нюанс: при отключении главного узла база становится автономной. Чтобы предотвратить возможное задвоение системных данных при реструктуризации, убедимся, что для предопределенных элементов метаданных не срабатывает автоматическая повторная инициализация.
  5. После завершения реструктуризации базы данных вернем главному узлу подчиненность, повторно вызвав метод:
    
    СсылкаНаГлавный = ПланыОбмена.Полный.НайтиПоКоду("ЦБ");
    ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавный);
    
  6. Запустим сеанс «1С:Предприятие» в периферии и штатно выполним обмен данными — конфликт версий конфигураций будет устранен.

Ошибка «Преобразование к типу Булево не может быть выполнено» при открытии документов

Если после синхронизации документ (например, «Заказ клиента») в подчиненном узле не открывается с ошибкой неверного типа, а в базе-источнике работает корректно, проанализируем реквизитный состав. При открытии формы типовая конфигурация обращается к связанным объектам и реквизитам: «Договор контрагента», «Соглашение», статусы партнера или банковские счета. Если был зарегистрирован и передан только сам документ или контрагент, но не перенесен связанный договор, чтение реквизита договора возвращает значение Неопределено. Попытка проверить булево свойство в коде вида Если Договор.ВестиРасчетыПоДоговору Тогда приводит к фатальному сбою. Для исправления ситуации достаточно найти все подчиненные справочники (договоры, соглашения) в базе-источнике, зарегистрировать их в обработке РегистрацияИзмененийДляОбмена и повторно выполнить сеанс выгрузки и загрузки данных.

← На главную