При работе с распределенными информационными базами (РИБ) в среде 1С администраторы и разработчики часто сталкиваются с ситуацией, когда штатный обмен данными внезапно блокируется. Типичный сценарий: в центральном узле обновили конфигурацию (иногда сразу на несколько релизов вперед), а при попытке выполнить синхронизацию на периферийной (подчиненной) базе система выдает критическую ошибку:
«Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла, для которого зарегистрированы изменения конфигурации. Необходимо произвести перенос изменений конфигурации в узел».
Попытка обновить подчиненный узел стандартным способом через Конфигуратор нередко заканчивается зависанием процесса реструктуризации на отметке 96% или аварийным завершением работы программы. В этой статье мы подробно проанализируем причины возникновения этой проблемы и рассмотрим надежные практические методы её решения. Для предотвращения подобных сбоев можно использовать обработку для автоматического последовательного обновления конфигурации узлов РИБ.
Для того чтобы эффективно бороться с проблемой, выясним причину её появления. В архитектуре РИБ крайне важно соблюдение полной идентичности метаданных между всеми узлами системы. Обмен данными не может быть выполнен, если структуры таблиц центральной и периферийной баз различаются хотя бы минимально. Ошибка возникает из-за следующих факторов:
Рассмотрим основные способы решения этой проблемы — от классических безопасных ИТ-методов до радикальных вариантов.
Это наиболее надежный и технически корректный способ, позволяющий сохранить все накопленные на периферийном узле данные и гарантированно обновить конфигурацию до нужного релиза.
Суть метода заключается в том, чтобы временно «обмануть» систему: снять с подчиненной базы признак распределенности, загрузить в нее готовый файл конфигурации напрямую из центральной базы, обновить базу данных и вернуть привязку к РИБ обратно.
Проанализируем этот процесс подробно по шагам:
Шаг 1. Выгрузка файла конфигурации из Центральной базы
Зайдем в Конфигуратор центральной базы. Перейдем в меню Конфигурация -> Сохранить конфигурацию в файл... и сохраним файл с расширением .cf (например, 1c_central.cf) на флешку, сетевой диск или отправим его на удаленную точку через интернет.
Шаг 2. Отвязка периферийной базы от главного узла
Поскольку база находится в режиме подчиненного узла РИБ, она заблокирована для ручного изменения конфигурации. Нам нужно временно снять эту блокировку. Для этого запустим периферийную базу в режиме Предприятия. Откроем внешнюю обработку или встроенную консоль кода и выполним следующую команду:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого кода периферийная база станет автономной. Закроем режим Предприятия.
Шаг 3. Загрузка конфигурации в подчиненный узел
Запустим Конфигуратор периферийной базы. Теперь меню конфигурации доступно для редактирования. Выполним следующие действия:
1c_central.cf и согласимся на замену существующей конфигурации.F5 (или кнопку «Обновить конфигурацию базы данных»). Начнется процесс реструктуризации таблиц. Система успешно применит все изменения структуры, так как конфигурация загружается целиком, минуя промежуточные коллизии обмена.Шаг 4. Восстановление связи с главным узлом
После успешного обновления метаданных запустим периферийную базу в режиме Предприятия. Теперь нам нужно вернуть ей статус подчиненного узла РИБ. Для этого выполним код, указав ссылку на наш предопределенный главный узел:
// Находим ссылку на главный узел в плане обмена
ГлавныйУзел = ПланыОбмена.[ИмяВашегоПланаОбмена].НайтиПоКоду("КодЦентральногоУзла");
Если ЗначениеЗаполнено(ГлавныйУзел) Тогда
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
Сообщить("Связь с главным узлом успешно восстановлена!");
КонецЕсли;
Примечание: Вместо написания кода можно воспользоваться готовыми обработками по изменению и восстановлению связи РИБ, которые широко представлены на профильных ресурсах. Для решения этой задачи подойдёт инструмент для отвязки информационной базы от РИБ.
После этого запустим стандартный обмен. Базы синхронизируются без ошибок, так как их метаданные теперь абсолютно идентичны.
Бывают ситуации, когда периферийная база из-за критической ошибки обновления конфигурации вообще отказывается запускаться в режиме Предприятия, из-за чего выполнить программный код отвязки от главного узла невозможно. В этом случае на помощь приходит штатный параметр запуска платформы 1С.
Разберем по шагам, как использовать этот метод:
/ResetMasterNodeПлатформа автоматически определит указанный ключ, сбросит признак подчиненности узла и откроет базу как полностью автономную. После этого обязательно закройте программу, удалите параметр /ResetMasterNode из настроек запуска (иначе база будет сбрасывать привязку при каждом старте) и переходите к обновлению конфигурации через загрузку файла .cf (Шаг 3 и Шаг 4 из предыдущего метода).
Этот метод часто выбирают начинающие специалисты из-за его кажущейся простоты, однако он таит в себе серьезную опасность. Рассмотрим его суть, чтобы понимать все риски.
Сценарий действий выглядит так: администратор заходит в центральную базу, выбирает в плане обмена нужный периферийный узел и нажимает кнопку «Создать начальный образ». Полученный файл новой базы данных переносится на периферийный компьютер и полностью заменяет собой старый «сломанный» файл базы.
Внимание! Оценка рисков метода:
Этот способ действительно решает проблему «в лоб» — вы получаете чистую, обновленную периферийную базу, которая сразу готова к обмену. Однако при замене старого файла базы на новый начальный образ вы полностью и безвозвратно уничтожаете все локальные данные, которые были внесены на периферийном узле с момента последней успешной синхронизации!
Даже если торговая точка уверяет, что «база все эти дни стояла и никто не работал», там могли быть созданы непроведенные документы, отредактированы элементы справочников, или в системе остались чеки ККМ, которые не успели уйти в центр. Применять данный метод можно исключительно в двух случаях:
Чтобы в будущем не сталкиваться с необходимостью принудительной отвязки баз и ручной загрузки тяжелых конфигурационных файлов, рекомендуем придерживаться простых правил администрирования РИБ: