Почему не переносятся изменения конфигурации РИБ на все подчиненные узлы в 1С и как это исправить?

← На главную

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

В этой статье мы подробно проанализируем причины возникновения этой проблемы, разберем особенности поведения платформы на различных релизах и рассмотрим несколько надежных практических способов ее решения.

Выясняем причину: почему ломается регистрация изменений?

Многие администраторы ошибочно полагают, что проблема кроется в зависших сеансах или открытом Конфигураторе в подчиненных базах. Однако, если Конфигуратор в подчиненном узле закрыт, а изменения все равно не регистрируются, дело в ошибке самой платформы 1С.

Рассмотрим детально внутренний механизм работы РИБ при обновлении конфигурации. Когда в центральной базе применяется обновление базы данных (клавиша F7), платформа автоматически регистрирует изменения основной конфигурации для всех узлов, входящих в соответствующий план обмена. При формировании первого же исходящего сообщения для конкретного подчиненного узла измененная конфигурация упаковывается в файл обмена.

Однако в линейках платформ 8.3.13 и 8.3.14 (включая популярный релиз 8.3.14.1565) присутствует критическая ошибка механизма регистрации изменений. Связана она с интеграцией поддержки расширений и патчей в распределенные базы:

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

Способ 1. Искусственная регистрация изменений («фиктивное изменение»)

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

Открываем центральную базу в режиме Конфигуратора.
Нам необходимо внести минимальное изменение в любой объект метаданных, которое не повлияет на логику работы программы, но заставит платформу пересчитать конфигурацию базы данных. Идеальный вариант — открыть любой общий модуль (например, ОбщегоНазначенияУТ) или модуль менеджера какого-либо справочника и добавить в конец любого метода обычный пробел или пустую строку комментария.
Нажимаем клавишу F7 (или меню «Конфигурация» — «Обновить конфигурацию базы данных»).
После успешного обновления платформа принудительно зарегистрирует изменения конфигурации для всех узлов во всех активных планах обмена. При выполнении следующего сеанса выгрузки подчиненные узлы гарантированно получат файлы с обновленной конфигурацией.

Способ 2. Временная блокировка входящего обмена (профилактика)

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

Разберем алгоритм действий по шагам:

Перед началом обновления в центральной базе временно запрещаем загрузку входящих файлов от периферийных баз. Сделать это можно несколькими способами:
- Временно отключить регламентные задания обмена данными через РегламентныеЗадания или в режиме «1С:Предприятие» в разделе администрирования.
- Если обмен идет через файловый каталог или FTP, можно временно переименовать папки входящих сообщений (например, из /In/ в /In_temp/), чтобы ЦБ просто не находила новые файлы.
Выполняем обновление конфигурации в центральной базе в штатном режиме (загрузка конфигурации, сохранение, запуск отложенного обновления данных).
После успешного обновления ЦБ запускаем процесс односторонней выгрузки (только исходящие сообщения) для каждого подчиненного узла. Платформа сформирует файлы обмена, содержащие новую структуру метаданных.
Убеждаемся, что файлы обмена для всех подчиненных узлов успешно сформированы и физически отправлены (или лежат в каталогах обмена).
Снимаем блокировку входящего потока данных (возвращаем регламентные задания в исходное состояние, переименовываем каталоги обратно). Теперь базы могут обмениваться в штатном двустороннем режиме.

Способ 3. Кардинальное решение через обновление платформы

Поскольку данная проблема признана официальным багом платформы 1С, наиболее правильным долгосрочным решением является обновление технологической платформы. В ветках 8.3.21, 8.3.22 и более современных версиях алгоритмы работы с кэшем метаданных и распределенными базами данных были кардинально переработаны. Ошибки автоматического затирания регистрации конфигурации при входящем обмене в них исправлены. Если у вас есть возможность, запланируйте обновление платформы на всех серверах и рабочих станциях вашей сети.

Способ 4. Принудительное обновление узла при рассинхронизации (через /ResetMasterNode)

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

Давайте разберем эту процедуру по шагам:

Выгружаем файл конфигурации из центральной базы. Для этого в Конфигураторе ЦБ выбираем пункт меню «Конфигурация» — «Сохранить конфигурацию в файл...» (сохраняем файл с расширением .cf, например, base_update.cf).
Открываем командную строку (CMD) на компьютере, где доступна подчиненная база данных, и запускаем ее Конфигуратор со специальным ключом для отключения связи с главным узлом:
```
"C:\Program Files\1cv8\8.3.14.1565\bin\1cv8.exe" config /F "ПутьКВашейБазе" /ResetMasterNode /N "Администратор" /P "Пароль"
```
Примечание: вместо ключа /F используйте ключ /S для клиент-серверного варианта базы данных.
После выполнения этой команды подчиненная база становится полностью автономной. Открываем ее Конфигуратор в обычном режиме. Меню работы с конфигурацией теперь разблокировано.
Выбираем меню «Конфигурация» — «Загрузить конфигурацию из файла...» (выбираем ранее сохраненный файл base_update.cf).
Обновляем конфигурацию базы данных подчиненного узла клавишей F7.

Теперь нам необходимо программно вернуть базу в режим подчиненного узла РИБ. Для этого запускаем подчиненную базу в режиме «1С:Предприятие» и выполняем следующий код во внешней обработке или через групповую обработку объектов:


СсылкаНаГлавныйУзел = ПланыОбмена.ПоПодразделениям.НайтиПоКоду("ЦБ"); 
Если ЗначениеЗаполнено(СсылкаНаГлавныйУзел) Тогда
    ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
    ВызватьИсключение "Связь с главным узлом РИБ успешно восстановлена!";
Иначе
    Сообщить("Не удалось найти главный узел по указанному коду!");
КонецЕсли;

После восстановления связи перезапустите обмен. Базы синхронизируются без потери накопленных данных регистрации.

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