Почему нельзя обновлять платформу только в центральной базе РИБ и как это ломает обмен данными

← На главную

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

Суть проблемы: Несовместимость версий при обмене данными

Рассмотрим типичную ситуацию: центральный узел (например, 1С:Управление торговлей 11.1) работает на старой платформе 8.3.6. В сети находятся десятки периферийных узлов (например, 1С:Розница), работающих на той же версии. Администратор принимает решение перевести центральную базу на платформу 8.3.18, надеясь, что режим совместимости конфигурации сохранит работоспособность обмена. Однако на практике при первой же попытке синхронизации система выдает ошибки, связанные с невозможностью прочитать файл сообщения обмена.

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

Разбор технических причин сбоя

Проанализируем детально, какие именно изменения в платформе 1С делают невозможным «прыжок» между версиями (например, с 8.3.6 на 8.3.18) в рамках одной РИБ:

Изменение формата сериализации данных (XDTO). Между выпусками 8.3.6 и 8.3.18 механизмы XDTO-сериализации претерпели существенные изменения. Платформа 1С при записи объекта в XML-сообщение записывает в заголовок версию формата. Если принимающая сторона видит версию, которую она «не знает», загрузка прерывается. Посмотрим на примерную структуру заголовка сообщения:


<v8msg:Message xmlns:v8msg="http://v8.1c.ru/8.2/managed/messages">
    <v8msg:Header>
        <v8msg:ExchangePlan>ОбменУправлениеТорговлейРозница</v8msg:ExchangePlan>
        <v8msg:To>Магазин_01</v8msg:To>
        <v8msg:From>ЦентральныйОфис</v8msg:From>
        <v8msg:MessageNo>125</v8msg:MessageNo>
        <!-- Здесь платформа новой версии может добавить атрибуты, -->
        <!-- которые старая версия воспримет как ошибку структуры -->
    </v8msg:Header>
    <v8msg:Body>
        ... данные ...
    </v8msg:Body>
</v8msg:Message>

Мифы о «Режиме совместимости». Важно понимать, что установка свойства РежимСовместимости в значение «8.3.6» внутри конфигурации влияет только на логику встроенного языка и запросов. Оно не откатывает механизмы формирования транспортных сообщений РИБ к старым алгоритмам. Платформа всегда использует актуальный движок формирования XML для своего релиза.
Технология FastInfoSet и оптимизация сжатия. В новых релизах платформы (начиная с 8.3.8 и выше) были внедрены оптимизации для работы с XML. Были изменены способы записи типов данных, таких как даты и ссылки. Старая платформа при парсинге такого файла натыкается на символы или структуры, которые она интерпретирует как некорректные.
Безопасность и цифровые подписи. Начиная с версии 8.3.10, были усилены требования к проверке целостности данных. Используются новые версии криптографических библиотек, поставляемых вместе с платформой. Если в настройках обмена задействованы механизмы защиты, старая платформа 8.3.6 не сможет даже начать дешифровку пакета от 8.3.18.

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

Выясним, почему нельзя просто «попробовать» запустить базу на новой платформе и, если не получится, быстро откатиться назад. Даже если сама конфигурация не меняется, при первом открытии тяжелой базы (объемом 300 Гб и более) на новой платформе происходит «тихое» обновление служебных таблиц SQL. Это включает в себя:

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

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

Практические рекомендации и решение задачи

Если вы оказались в ситуации, когда обновить платформу на всех 68 магазинах одновременно невозможно, а центральный узел требует обновления, рассмотрим возможные варианты действий:

Вариант 1: Синхронное обновление всех узлов

Это единственный официальный и безопасный метод. Необходимо подготовить пакеты автоматической установки платформы для всех периферийных компьютеров. Обновление должно происходить в «технологическое окно», когда обмен данными приостановлен на всей сети. Сначала обновляется платформа на клиентах, затем на сервере центрального узла.

Вариант 2: Использование «Сервера-прослойки»

Если обновление магазинов затягивается, можно организовать временную схему. Для этого создается отдельный экземпляр центральной базы, который продолжает работать на старой платформе 8.3.6 исключительно для целей приема и отправки сообщений РИБ. Основная работа пользователей при этом переносится в базу на новой платформе 8.3.18. Данные между этими двумя «центрами» синхронизируются локально.

Вариант 3: Переход на универсальный обмен данными (XML)

Вместо жесткого механизма РИБ можно перенастроить синхронизацию через «Универсальный обмен данными в формате XML». Этот метод менее чувствителен к версии платформы, так как использует внешние правила обмена (созданные в Конвертации данных). Однако этот путь требует полной переработки логики регистрации изменений и может быть крайне трудоемким для сети из 60+ магазинов.

Вывод

Проанализировав ситуацию, мы видим, что запуск старой конфигурации под новой платформой в условиях распределенной базы — это высокий риск. Платформа 1С официально требует единообразия версий во всех узлах РИБ. Допускается лишь незначительное различие в номерах сборок в рамках одного минорного релиза, но разрыв между 8.3.6 и 8.3.18 гарантированно приведет к ошибкам «Несоответствие версии сообщения обмена».

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