← На главную

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

Проанализируем архитектурные причины такого поведения платформы 1С и разберем конкретные шаги для устранения проблемы.

Причина 1: Превышение лимита повторов в регламентном задании

Выясним, почему ручной запуск работает, а регламентное задание «засыпает». В свойствах каждого регламентного задания в 1С предусмотрены параметры реакции на аварийное завершение:

1. Количество повторов при аварийном завершении — число автоматических попыток перезапуска фонового процесса при возникновении исключительной ситуации.
2. Интервал повтора — пауза между этими попытками (например, каждые 10 секунд).

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

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

Причина 2: Блокировка файлов клиентами облачной синхронизации

Клиенты Яндекс Диска или Dropbox работают как фоновые службы операционной системы, отслеживающие системные события файловой структуры. В момент, когда 1С формирует исходящий архив обмена (например, Message_001_002.zip), происходят следующие конфликты:

1. Захват дескриптора (Sharing Violation): облачный агент моментально пытается перехватить созданный файл и начать его закачку в облако, блокируя доступ на чтение, запись или удаление со стороны платформы 1С.
2. Чтение неполного файла: на принимающей стороне 1С по расписанию пытается прочитать входящее сообщение, которое еще не успело полностью загрузиться из сети на диск. В результате 1С выдает ошибку повреждения ZIP-архива или формата XML.
3. Коллизии имен файлов: при одновременной модификации или задержках сети облачные клиенты создают копии с постфиксами вроде Message_001_002 (2).zip. Типовой механизм РИБ не умеет обрабатывать файлы с измененными именами, сообщение пропускается, и номера сообщений обмена рассинхронизируются.

Причина 3: Специфика файлового режима работы базы

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

---

Пошаговое решение проблемы

Разберем по шагам, как исправить сбои автоматической синхронизации и сделать работу распределенной базы надежной.

Шаг 1: Корректировка параметров регламентного задания

Откроем список регламентных заданий через раздел Администрирование — Обслуживание — Регламентные и фоновые задания (или в конфигураторе) и проанализируем настройки задания обмена данными для каждого узла:

1. Перейдем в параметры аварийного завершения задания. Если там установлено малое количество повторов с жестким интервалом (например, 3 раза по 10 секунд), снимем ограничение или настроим интервал так, чтобы кратковременные сетевые сбои не приводили к блокировке всего расписания.
2. Разнесем расписания обменов по времени. Если у нас 3 узла РИБ, не следует запускать синхронизацию по всем трем направлениям в одну и ту же минуту. Сделаем сдвиг в 5–10 минут между узлами, чтобы снизить нагрузку на дисковую подсистему и сеть.
3. Увеличим период запуска: для розничных точек интервал в 15–30 минут обычно является достаточным и позволяет облачным агентам гарантированно завершить закачку и отдачу пакетов.

Шаг 2: Переход на надежный транспорт обмена (FTP или веб-сервисы)

Практика показывает, что использование сторонних облачных дисков для РИБ является нестабильным костылем. Рассмотрим два правильных варианта организации транспорта:

1. Обмен через FTP-сервер:

   1С умеет работать с FTP напрямую через встроенные механизмы без сторонних фоновых утилит. При передаче через FTP файл записывается и читается строго атомарно, что исключает блокировку дескрипторов файлов и появление дублей вида (2).zip. Для этого достаточно поднять собственный FTP-сервер (например, на базе IIS или FileZilla Server) либо арендовать защищенный хостинг.

2. Прямой обмен через веб-сервисы (HTTP/HTTPS):

   Конфигурация 1С:Розница 2.1 на базе Библиотеки стандартных подсистем поддерживает синхронизацию напрямую через веб-сервисы. Центральная база публикуется на веб-сервере (IIS или Apache). Периферийные базы настраиваются на отправку данных по протоколу HTTP/HTTPS прямо в центральную базу. Это снимает необходимость в промежуточных файлах и обеспечивает максимальную скорость и надежность.

Шаг 3: Настройка буферных каталогов и антивируса (если облако сохраняется)

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

1. Настроим выгрузку из 1С в промежуточную локальную папку, которая не синхронизируется облачным агентом.
2. Перемещение архива в каталог Яндекс Диска или Dropbox настроим через отдельный пакетный скрипт только после того, как 1С завершит формирование файла и закроет поток.
3. Добавим рабочие каталоги обмена и каталоги временных файлов 1С в список исключений антивирусного сканера операционной системы, чтобы исключить дополнительную блокировку архивов в момент их распаковки.

Шаг 4: Восстановление журнала регистрации

Если база аварийно закрывается при попытке открыть журнал регистрации, это указывает на повреждение или фрагментацию файла журнала (SQLite). Сбои при записи событий обмена в поврежденный журнал приводят к падению фоновых заданий.

Для исправления ситуации выполним процедуру сокращения журнала через конфигуратор: меню Администрирование — Настройка журнала регистрации — Сократить, указав удаление записей до определенной даты, либо временно переместим файл журнала из каталога базы данных для формирования нового чистого журнала.