Процедура обновления распределенной информационной базы (РИБ) в экосистеме 1С:Предприятие 8 часто становится камнем преткновения для системных администраторов и ответственных пользователей. В отличие от монолитной базы, где обновление сводится к запуску установщика или обновлению конфигурации в режиме предприятия, распределенная архитектура требует строгой последовательности действий. Нарушение очередности шагов может привести к рассинхронизации данных, блокировке узлов или полной остановке работы удаленных филиалов.
Центральным элементом всей системы является Центральный узел, который выступает в роли донора конфигурации и правил обмена. Именно с него начинается любой процесс модернизации. Перед тем как приступать к техническим манипуляциям, необходимо убедиться, что у вас есть актуальные резервные копии всех participating узлов. Это критически важный этап, так как откат изменений в РИБ — процедура значительно более сложная, чем простое восстановление из бэкапа в обычной базе.
В данной статье мы детально разберем алгоритм действий для различных сценариев: от планового обновления типовой конфигурации до сложной доработки уникальных обработок. Вы узнаете, как правильно использовать механизм Администрирование → Синхронизация данных, какие настройки проверять в первую очередь и как интерпретировать протоколы обмена, если что-то пошло не так.
Подготовительный этап и анализ текущей схемы
Прежде чем запускать процесс обновления, необходимо провести аудит текущей топологии вашей распределенной базы. Понимание того, какие узлы являются центральными, а какие периферийными, определяет вектор ваших дальнейших действий. В классической схеме «Центр-Периферия» обновление конфигурации всегда происходит сначала в центре, а затем транслируется на подчиненные узлы через файлы обмена или прямое подключение.
Важно проверить статус всех активных сеансов. Если в момент обновления кто-то из пользователей будет вносить данные в периферийный узел, эти изменения могут не попасть в общий поток или вызвать конфликт при следующей выгрузке. Рекомендуется запланировать работы на время, когда нагрузка на систему минимальна, например, в конце рабочего дня или в выходные.
⚠️ Внимание: Никогда не пытайтесь обновить конфигурацию периферийного узла в режиме Конфигуратора вручную, если он подключен к схеме РИБ. Это приведет к необратимому нарушению идентификаторов объектов и разрыву связи с центром. Все изменения должны приходить только через механизм обмена.
Также стоит убедиться в достаточном объеме свободного места на дисках серверов и рабочих станций. Процесс выгрузки и загрузки данных обмена может временно увеличить размер файлов базы данных в несколько раз. Если вы используете файловый вариант хранения, проверьте права доступа к сетевым папкам, где расположены каталоги обмена.
☑️ Готовность к обновлению РИБ
Обновление Центрального узла РИБ
Начинаем процедуру с главного узла распределенной базы. Если вы используете типовую конфигурацию, например, 1С:Бухгалтерия предприятия 3.0 или 1С:Управление торговлей 11, процесс начинается со стандартного обновления через механизм поддержки конфигурации. Зайдите в базу в режиме Конфигуратор под пользователем с полными правами.
В меню выберите Конфигурация → Поддержка → Обновить конфигурацию. Система предложит выбрать файл обновления (.cfu). После выбора файла мастер обновления проанализирует изменения и предложит варианты слияния, если в базе были внесены нестандартные правки. В случае РИБ крайне важно внимательно отнестись к этому этапу, так как любые конфликты объектов могут повлиять на правила регистрации изменений.
После успешного обновления конфигурации необходимо обновить саму базу данных. Перейдите в режим 1С:Предприятие. Система автоматически обнаружит несоответствие версии конфигурации и версии базы данных, предложив выполнить обновление. Этот процесс может занять значительное время в зависимости от объема накопленных данных и сложности изменений в структуре таблиц.
Перед обновлением Центрального узла отключите все правила обмена с периферийными узлами в разделе «Администрирование» → «Синхронизация данных». Это предотвратит попытку периферии забрать «половинчатую» конфигурацию в момент обновления центра.
Критически важным шагом после обновления является проверка работы регистраторов изменений. Убедитесь, что механизм РИБ корректно фиксирует новые объекты. Для этого можно создать тестовый документ и проверить, появился ли он в списке зарегистрированных изменений. Если регистрация не работает, обмен с периферией будет невозможен.
Настройка и выгрузка данных для Периферии
Когда Центральный узел успешно обновлен и протестирован, наступает этап трансляции изменений на удаленные офисы. В современных версиях платформ 1С:Предприятие 8.3 этот процесс максимально автоматизирован через обработку Синхронизация данных. Вам не нужно вручную выгружать файлы через старые механизмы, если не требуется специфическая настройка.
Зайдите в раздел настройки синхронизации. Выберите нужный узел периферии из списка. В карточке настройки обмена система автоматически определит, что конфигурация центра новее, чем у узла. Вам будет предложено выполнить обновление конфигурации удаленного узла. Согласитесь с этим действием.
Система сформирует файл обновления конфигурации и поместит его в каталог обмена или передаст напрямую, в зависимости от выбранного варианта подключения. Для файловых баз это обычно папка, доступная по сети, а для SQL-версий может использоваться прямое соединение. Убедитесь, что путь к каталогу обмена указан корректно и у учетной записи 1С есть права на запись в эту директорию.
| Тип узла | Действие администратора | Роль в обновлении | Риск ошибки |
|---|---|---|---|
| Центральный | Загрузка .cfu, обновление БД | Источник новой версии | Высокий (остановка всей сети) |
| Периферийный | Запуск получения данных | Приемник обновлений | Средний (локальный сбой) |
| Промежуточный | Трансляция трафика | Ретранслятор | Высокий (разрыв цепочки) |
После того как файл обновления сформирован в центре, периферийный узел должен его подхватить. При следующем запуске базы на удаленном компьютере или при ручном запуске обработки синхронизации, система обнаружит новый файл конфигурации и предложит обновиться. Пользователь на периферии должен следовать инструкциям мастера, не прерывая процесс.
Алгоритм обновления периферийных узлов
На стороне периферийного узла процесс выглядит иначе. Пользователь не должен иметь доступа к режиму Конфигуратора для загрузки файлов поддержки. Все происходит в режиме Предприятия. При запуске синхронизации система считывает файл обновления из папки обмена.
Если используется прямое подключение, обновление конфигурации произойдет автоматически в фоновом режиме перед началом выгрузки данных. Если же используется файловый вариант, пользователю может потребоваться вручную указать путь к файлу обновления, если автоматическое обнаружение не сработало. Это часто случается при проблемах с сетевыми правами доступа.
После обновления конфигурации на периферии обязательно нужно выполнить обновление базы данных. Этот этап аналогичен тому, что проделывалось на центральном узле: перестройка таблиц, индексация и конвертация данных. Только после успешного завершения этого этапа узел готов к приему и отправке данных.
⚠️ Внимание: Если в периферийной базе были созданы уникальные объекты (справочники, документы), которых нет в центре, и они не были предварительно зарегистрированы, при обновлении они могут быть помечены на удаление или вызвать конфликт имен. Всегда сверяйте нумерацию объектов перед масштабными обновлениями.
Важно контролировать время простоя периферийного узла. Обновление больших баз может занять от 15 минут до нескольких часов. В это время работа с базой невозможна. Рекомендуется уведомлять сотрудников филиала о техническом перерыве заранее.
Запуск обмена и контроль целостности данных
После того как все узлы обновлены до единой версии конфигурации и базы данных, необходимо возобновить обмен данными. Включите ранее отключенные правила синхронизации на Центральном узле. Запустите первую выгрузку данных вручную, чтобы убедиться, что канал связи работает корректно.
Обратите внимание на журнал регистрации. В нем не должно быть ошибок вида «Объект не найден» или «Конфликт версий». Если такие ошибки присутствуют, значит, обновление прошло не на всех узлах, или где-то осталась старая версия конфигурации. В этом случае необходимо отключить проблемный узел от схемы и провести его обновление заново в изолированном режиме.
Особое внимание уделите ссылочной целостности. Проверьте ключевые документы: проведите выборочный анализ счетов-фактур, накладных или заказов клиентов. Убедитесь, что ссылки на контрагентов и номенклатуру не «разлетелись». В РИБ потеря ссылки на общий элемент справочника — частая проблема при некорректном слиянии данных.
Что делать, если обмен «завис»?
Если процесс выгрузки или загрузки данных завис на определенном проценте, проверьте размер файла обмена. Если он аномально велик (гигабайты), возможно, накопилось слишком много изменений за период простоя. Попробуйте выполнить обмен частями, ограничив период выгрузки в настройках синхронизации, либо очистите журнал регистрации на старом узле (только если данные уже приняты!).
Для контроля можно использовать отчет «Анализ состояния синхронизации». Он покажет время последней успешной выгрузки и загрузки для каждого узла. Если расхождение во времени превышает допустимый регламент, значит, автоматическое расписание не срабатывает и требуется вмешательство администратора.
Типовые ошибки и методы их устранения
В процессе обновления РИБ администраторы часто сталкиваются с рядом специфических проблем. Одна из самых распространенных — ошибка «Неверный пароль пользователя» или «Отказано в доступе» при попытке записи в каталог обмена. Это решается проверкой прав доступа NTFS к сетевой папке для учетной записи, под которой запускается сервис 1С или пользователь.
Другая частая проблема — рассинхронизация версий платформы. Если на Центре стоит платформа версии 8.3.25, а на периферии 8.3.20, некоторые новые функции конфигурации могут не работать или вызывать сбои. Перед обновлением конфигурации всегда сверяйте минимально требуемую версию платформы в файле описания обновления (.txt).
Также возможна ситуация «двойной регистрации», когда один и тот же документ пытается выгрузиться дважды с разными идентификаторами. Это лечится перепроведением документов и очисткой таблицы регистрации изменений через специальную обработку «Удаление помеченных объектов» (с осторожностью!) или специализированные обработки от фирмы 1С для РИБ.
Золотое правило РИБ: Конфигурация обновляется строго от Центра к Периферии. Данные могут передаваться в обе стороны, но структура базы меняется только сверху вниз. Нарушение этого порядка ведет к краху схемы обмена.
Если вы столкнулись с ошибкой, которую не удается решить стандартными методами, не пытайтесь «починить» базу прямым редактированием таблиц SQL. Это гарантированно нарушит служебные поля РИБ (например, _RIB_ префиксы), и восстановление потребует полной пересоздания распределенной базы с нуля.
Можно ли обновить только один периферийный узел, игнорируя остальные?
Технически это возможно, но категорически не рекомендуется. Если конфигурация на одном узле будет отличаться от других, правила обмена могут перестать работать, так как они зависят от идентичности метаданных на всех участниках схемы. Это приведет к ошибкам конвертации данных.
Что делать, если после обновления пропали данные на периферии?
Скорее всего, данные не пропали, а просто еще не выгрузились из Центра. Проверьте журнал регистрации на Центральном узле: есть ли там записи об изменениях? Если да, запустите выгрузку вручную. Если записей нет, значит, изменения не регистрировались из-за сбоя в работе регистраторов во время обновления.
Как обновить РИБ, если нет доступа к серверу Центра?
Без доступа к Центральному узлу полноценное обновление схемы невозможно. Вы можете обновить конфигурацию на периферии локально, но это разорвет связь с РИБ. Для восстановления связи потребуется вмешательство администратора Центрального узла для перенастройки правил обмена и повторной инициализации узла.
Влияет ли обновление платформы 1С на работу РИБ?
Да, влияет. Желательно, чтобы на всех узлах стояла одинаковая версия платформы или версия на периферии была не ниже, чем на Центре. Обновление платформы часто требует перезагрузки сервисов 1С:Предприятия и может временно остановить фоновые задания обмена.
Нужно ли останавливать службу 1С:Предприятия при обновлении?
При обновлении конфигурации через клиентское приложение остановка серверной службы не обязательна, но желательна для исключения блокировок. При обновлении самой платформы (exe-файлов) остановка служб ragent и кластера серверов обязательна на всех машинах, где производится обновление.