Как перейти на новую версию сервера 1С:Предприятие под Linux без потери кластера

· 9 мин

Содержание

Чтобы обновить платформу 1С на сервере Linux, не нужно удалять старую версию и пересоздавать кластер. Порядок такой: остановить службу сервера , установить пакеты новой версии рядом со старой, запустить службу новой версии с тем же рабочим каталогом кластера — и проверить, что базы открываются. Кластер, информационные базы и их настройки хранятся в рабочем каталоге, а не в бинарниках платформы, поэтому при аккуратном обновлении они остаются на месте.

Главное заблуждение — что обновление сервера затронет сами базы. Нет: платформа и прикладное решение (конфигурация) — разные уровни. Обновление сервера 1С:Предприятие меняет только исполняемые файлы (ragent, rmngr, rphost). Структуру базы платформа при необходимости сконвертирует отдельно, при первом запуске в Конфигураторе.

Инструкция ниже — пошаговая, для клиент-серверного варианта на 64-битном Linux: разберём подготовку, работу с дистрибутивами и репозиториями, установку на Debian/Ubuntu и RHEL/CentOS, переключение службы, типичные ошибки запуска и финальную проверку.

Что проверить и зарезервировать до обновления

Сервер 1С работает под служебным пользователем usr1cv8. Его бинарники лежат в /opt/1cv8/x86_64/<версия>/, а данные кластера — в рабочем каталоге агента (каталог вида reg_1541, по умолчанию в домашнем каталоге usr1cv8: /home/usr1cv8/.1cv8/). Точный путь задаётся параметром -d в юните службы — его стоит найти заранее.

Обновление требует остановки службы сервера. Все активные сеансы пользователей оборвутся, фоновые и регламентные задания прервутся. Планируйте работы на окно, когда в базе никого нет, и предупредите пользователей.

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

  • 💾 База данных. Для PostgreSQL — pg_dump конкретной базы или pg_dumpall. Для файла .dt — выгрузка из Конфигуратора. Без свежего бэкапа базы обновление начинать нельзя.
  • 📁 Рабочий каталог кластера. Скопируйте каталог reg_1541 целиком — там список баз, администраторы кластера, профили безопасности и настройки отказоустойчивости.
  • 📝 Номер текущей версии. Запишите rac --version или посмотрите каталог в /opt/1cv8/x86_64/. Если новая версия не заведётся, вы быстро откатитесь на старую.
Готовность к обновлению сервера
Выполнено: 0 / 6

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

Где взять дистрибутив сервера и как подключить репозиторий

Дистрибутив сервера для Linux берут в личном кабинете пользователя 1С (раздел обновлений платформы технологической платформы) или на диске ИТС. Для сервера нужен комплект под архитектуру x86_64 (64 бита) — тот же, что у вашей ОС. 32-битный сервер на боевой базе не ставят.

Дистрибутив поставляется в двух форматах:

  • Отдельные .deb / .rpm пакеты — по одному на компонент. Для сервера обязательны пакет common (общие файлы) и пакет server. Пакет server-nls добавляет национальные языки интерфейса — ставьте, если нужен не только русский.
  • Единый архив со всеми пакетами внутри — распаковываете и ставите нужные.

Имена пакетов содержат номер версии, поэтому пакеты разных версий не конфликтуют и устанавливаются в отдельные каталоги. Это и позволяет держать старую и новую платформу одновременно.

Если в компании много серверов, удобнее поднять внутренний репозиторий (apt или yum) и складывать туда пакеты платформы — тогда обновление сводится к одной команде установки. Но для одного сервера достаточно скопировать пакеты на машину и поставить их напрямую.

Скачивайте пакеты на локальную папку сервера (например, /tmp/1c-server/), а не в системные каталоги. После установки временную папку можно удалить — бинарники платформы уже скопированы в /opt/1cv8/.

Установка новой версии сервера на Debian, Ubuntu и RHEL

Порядок одинаковый для всех дистрибутивов: остановить старую службу, поставить пакеты, разрешить зависимости. Отличаются только менеджеры пакетов.

Шаг 1. Остановите текущую службу сервера. Точное имя юнита зависит от версии установки, поэтому сначала найдите его:

systemctl list-units '*1c*' --type=service

Остановите найденную службу (имя обычно вида srv1cv8-<версия>@default или классическое srv1cv83):

sudo systemctl stop srv1cv8-8.3.XX.YYYY@default.service

Убедитесь, что процессы завершились:

ps aux | grep -E 'ragent|rmngr|rphost'

В выводе не должно остаться строк, кроме самой grep. Если процессы висят, дайте им минуту завершиться штатно, прежде чем снимать принудительно.

Debian и Ubuntu (.deb)

Перейдите в папку с пакетами и установите их. dpkg поставит файлы, а apt-get -f install подтянет недостающие зависимости:

sudo dpkg -i 1c-enterprise-8.3.XX.YYYY-common*.deb \
            1c-enterprise-8.3.XX.YYYY-server*.deb
sudo apt-get install -f

RHEL, CentOS и Alt Linux (.rpm)

Через штатный менеджер пакетов, который сам разрешит зависимости:

sudo yum localinstall 1c-enterprise-8.3.XX.YYYY-common*.rpm \
                      1c-enterprise-8.3.XX.YYYY-server*.rpm

На системах с dnf команда та же с заменой yum на dnf. На Alt Linux — apt-get install из локального файла или rpm -ihv.

Шаг 2. Проверьте зависимости. Серверу 1С, несмотря на отсутствие графики, нужны шрифты и библиотеки для формирования табличных и печатных форм. Обычно это fontconfig, набор TrueType-шрифтов, ImageMagick (libMagickWand) и libgsf. Если apt-get -f install или yum их не доставили, установите вручную. Проверьте и локаль: в системе должна быть сгенерирована ru_RU.UTF-8 (locale -a | grep ru_RU).

Шаг 3. Проверьте, что бинарники новой версии на месте:

ls /opt/1cv8/x86_64/

Вы должны увидеть каталог со старым номером версии и рядом — с новым. Старый пока не удаляйте: он нужен для отката.

Переключение службы и кластера на новую версию

Пакеты новой версии создают собственный юнит systemd, но он по умолчанию может смотреть в другой рабочий каталог. Задача — запустить службу новой версии с тем же каталогом кластера -d, что был у старой. Тогда новый ragent подхватит существующий список баз и настройки.

  1. Посмотрите параметры старой службы, прежде всего значение -d (рабочий каталог) и номера портов. Классически это агент 1540, менеджер кластера 1541, диапазон рабочих процессов 1560–1591.

    systemctl cat srv1cv83.service
    
  2. В юните новой версии (или в его override через systemctl edit) укажите тот же каталог -d и те же порты. Параметры кластера хранятся в этом каталоге, поэтому менять их не нужно.

  3. Отключите старую службу и включите новую:

    sudo systemctl disable --now srv1cv83.service
    sudo systemctl enable --now srv1cv8-8.3.XX.YYYY@default.service
    
  4. Запустите ras (сервер администрирования), если он у вас вынесен в отдельную службу, — он нужен утилите rac и консоли администрирования.

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

Клиентские приложения на рабочих местах тоже должны уметь работать с новой версией. Если на клиентах настроен запуск конкретной версии платформы, обновите и их — иначе при подключении появится требование установить соответствующую версию.

Разбор ошибок запуска сервера после обновления

Если после переключения службы базы не открываются, почти всегда причина — в несовпадении каталога, прав или зависимостей. Сопоставьте симптом с причиной.

Диагностика: выберите симптом

Общее правило диагностики: сначала смотрите systemctl status и journalctl -u <служба>, затем технологический журнал сервера, если он настроен. Не пересоздавайте кластер и не удаляйте базы в попытке «починить» — почти все ошибки запуска решаются правкой параметров службы и прав на каталог.

Проверка работоспособности кластера после обновления

Когда служба поднялась, убедитесь, что кластер отвечает и базы доступны. Проверка по уровням, от процессов к пользовательскому сценарию.

1. Версия и процессы. Убедитесь, что запущена именно новая версия:

rac --version
ps aux | grep -E 'ragent|rmngr|rphost'

Должны быть живы агент (ragent), менеджер кластера (rmngr) и хотя бы один рабочий процесс (rphost).

2. Кластер и базы через rac. Для команд rac нужен запущенный ras. Получите список кластеров, затем — список баз в нём:

rac cluster list
rac infobase summary list --cluster=<uuid-кластера>

Если список баз непустой и совпадает с тем, что был до обновления, — кластер подхватил рабочий каталог корректно. Если не уверены в параметрах команды, посмотрите rac help.

3. Порты. Проверьте, что сервер слушает рабочие порты (агент 1540, менеджер 1541):

ss -tlnp | grep -E '154[01]'

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

Когда всё работает несколько дней без сбоев, старый каталог версии в /opt/1cv8/x86_64/ можно удалить, чтобы освободить место. До этого держите его как точку отката.

Частые ошибки и как их избежать

Отдельно о том, что чаще всего ломает обновление, — это не повтор шагов, а узкие места процесса.

  • 🔁 Новую службу запустили с «чистым» каталогом. Самая частая проблема: ragent поднялся, но видит пустой кластер, потому что -d указывает не туда. Всегда сверяйте рабочий каталог новой службы со старой.
  • 🗑 Удалили старую версию до проверки. Пока новая версия не отработала хотя бы день, старые бинарники — ваш единственный быстрый откат. Не торопитесь их сносить.
  • 🔑 Сбросили права на каталог после ручного копирования. Скопировали reg_1541 под root — и служба под usr1cv8 не может его прочитать. Возвращайте владельца.
  • ⏱ Обновились в рабочее время. Остановка службы рвёт сеансы и регламентные задания. Делайте только в окно обслуживания.
  • 🧩 Забыли про клиентов и релиз конфигурации. Платформу обновили, а клиентские места или релиз конфигурации остались несовместимыми. Проверяйте совместимость заранее.
Нужно ли удалять старую версию платформы перед установкой новой?
Нет. Пакеты новой версии ставятся в отдельный каталог и не конфликтуют со старой. Старую версию оставляют как точку отката и удаляют только после нескольких дней стабильной работы.
Сохранится ли список баз и настройки кластера после обновления?
Да, если новая служба запущена с тем же рабочим каталогом (-d), что и старая. Список баз, администраторы и настройки лежат в каталоге reg_1541, а не в бинарниках платформы.
Обновляется ли база данных при обновлении сервера?
Сервер меняет только исполняемые файлы платформы. Структура базы при необходимости конвертируется отдельно — при первом открытии в Конфигураторе. Для минорных обновлений в режиме «Предприятие» это обычно проходит прозрачно.
Можно ли откатиться на старую версию, если новая не заработала?
Да: остановите новую службу, запустите службу старой версии с тем же рабочим каталогом. Поэтому старые бинарники и резервная копия каталога кластера нужны до окончания проверки.
Обязательно ли обновлять клиентские места вместе с сервером?
Клиент должен уметь работать с версией сервера. Если на рабочих местах настроен запуск конкретной версии платформы, их обновляют вместе с сервером, иначе появится требование установить нужную версию.