Перенос информационной базы из файлового режима в клиент-серверный (MS SQL) — это стандартная процедура при росте нагрузки, однако в распределенных информационных базах (РИБ) она часто сопровождается критической ошибкой: «Конфигурация узла распределенной ИБ не соответствует ожидаемой!». Ситуация осложняется тем, что визуально конфигурации в центре и в узлах могут казаться идентичными, но на уровне внутренних идентификаторов (сигнатур) возникает рассогласование. В рамках данной статьи мы подробно разберем причины этой проблемы и изучим пошаговые алгоритмы ее решения, основываясь на практическом опыте специалистов.
Рассмотрим, почему стандартный механизм обмена дает сбой при смене архитектуры хранения данных. Основная причина кроется в том, как платформа 1С:Предприятие 8.3 формирует и проверяет версию конфигурации. При выгрузке данных в формат .dt и последующей загрузке в MS SQL сервер может произойти микро-обновление метаданных, которое меняет внутренний номер версии (версионный идентификатор). Подчиненный узел, получая файл обмена, сравнивает свою текущую сигнатуру с той, что пришла из центра. Если они не совпадают хотя бы в одном символе, система блокирует загрузку изменений, защищая базу от потенциальной потери целостности данных.
Дополнительным фактором выступают ошибки конкретных релизов платформы (например, ветки 8.3.13 и 8.3.14), где механизмы Директ.Банка или фоновые обновления 1СПАРК Риски могут блокировать вход в программу или корректное завершение реструктуризации при приеме пакета обмена.
Проанализируем сообщения разработчиков и опыт пользователей. Одной из наиболее частых причин является баг в платформе. Как отмечено в обсуждении, на версиях ниже 8.3.14.1694 данная проблема проявлялась систематически. Поэтому первым делом мы должны убедиться, что на всех узлах (и в центре, и на периферии) установлена актуальная и, что крайне важно, одинаковая версия платформы.
Если вы столкнулись с ошибкой на старых релизах, рекомендуется выполнить обновление до стабильной версии (например, из веток 8.3.18 или 8.3.22, если конфигурация «Розница 2.2» это позволяет). Это устраняет ошибки некорректного сравнения таблиц Config и ConfigSave.
Иногда обмену мешают «зависшие» блокировки или попытки программы обновиться в фоновом режиме. Если вы видите ошибку загрузки приоритетных данных или сообщение о том, что «Вход в программу временно невозможен», выполним следующие действия:
/AllowExecuteScheduledJobs –Off.cf.ПараметрыРаботыПрограммы, если там застрял флаг незавершенного обновления.Если обновление платформы не помогло, перейдем к более радикальным методам синхронизации метаданных. Суть метода заключается в принудительной перезаписи конфигурации подчиненного узла эталонным файлом из центральной базы.
Разберем алгоритм действий:
1cv8.cf).
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
1cv8.cf. Важно использовать именно «Загрузить», а не «Сравнить/Объединить», чтобы полностью идентифицировать структуру.
Центр = ПланыОбмена.ПоМагазину.НайтиПоКоду("КодЦентральногоУзла");
ПланыОбмена.УстановитьГлавныйУзел(Центр);
Рассмотрим уникальный случай, когда обычная загрузка .cf не меняет внутреннюю сигнатуру базы. Как показывает практика, иногда платформа «считает» загружаемый файл идентичным текущему и не запускает полную реструктуризацию. В этом случае нам поможет метод выгрузки в XML-файлы:
.cf. Этот двойной проход принудительно обновляет все внутренние идентификаторы в таблице Config MS SQL сервера.Проанализируем ситуацию, когда проблема сохраняется даже после манипуляций с конфигурацией. Часто сервер 1С кэширует метаданные базы. Чтобы сбросить этот кэш, выполним следующие шаги:
srvinfo (обычно в C:\Program Files\1cv8\srvinfo) и удалим содержимое папки reg_1541 (кроме файлов конфигурации самого кластера). Будьте осторожны, это сбросит настройки всех баз в кластере, поэтому лучше удалять только папку с UID конкретной базы.Для опытных администраторов существует также «тяжелая артиллерия» — работа напрямую с MS SQL. Если конфигурации гарантированно совпадают, но сигнатура не дает выполнить обмен, можно попробовать очистить таблицу Config в подчиненном узле командой DELETE FROM Config, а затем сразу зайти в конфигуратор и загрузить исправный .cf. Внимание: этот метод требует наличия полной резервной копии базы данных!
Посмотрим на ситуацию в перспективе. Чтобы избежать подобных сбоев при переносе РИБ на SQL в будущем, рекомендуем соблюдать следующие правила:
.dt обязательно делайте первый запуск центральной базы в режиме предприятия, чтобы все фоновые обновления метаданных завершились до того, как вы начнете синхронизацию с узлами.Таким образом, мы рассмотрели комплекс мер от простого обновления платформы до сложных манипуляций с файловой структурой метаданных. Последовательное выполнение этих шагов позволяет восстановить работоспособность обмена без необходимости пересоздания начальных образов подчиненных узлов.