Работа с распределенными информационными базами (РИБ) в условиях нестабильного или медленного интернет-соединения всегда сопряжена с рисками. Типичная ситуация: при попытке обновить центральный узел сразу на несколько релизов, подчиненные узлы не могут корректно принять тяжелые сообщения обмена, содержащие изменения конфигурации. В результате синхронизация «отваливается» (поможет мониторинг ошибок обмена с уведомлением в Telegram), узлы остаются на разных версиях программного продукта, а работа торговой точки может быть парализована.
Рассмотрим детально, как выйти из этой ситуации, восстановить работоспособность системы без потери данных и настроить транспорт так, чтобы подобные проблемы не повторялись. Проанализируем технические нюансы ручной «привязки» узлов и механизмы оптимизации обмена.
Выясним причину, почему стандартный механизм обновления РИБ подводит при плохом канале связи. Когда мы обновляем центральный узел, 1С формирует сообщение обмена, в которое упаковывается файл конфигурации (расширение .cf или информация об изменениях). Если мы «прыгаем» через три релиза (например, с 2.3.4 на 2.3.6), объем данных в одном сообщении может достигать нескольких сотен мегабайт.
Медленный интернет не позволяет передать такой объем за один сеанс, а стандартный механизм 1С при работе с FTP не всегда корректно поддерживает докачку. Кроме того, многие бесплатные или бюджетные FTP-серверы имеют жесткие лимиты на размер хранилища (например, 500 Мб). При превышении этого лимита файл либо удаляется, либо обрезается, что приводит к невозможности обновления подчиненного узла.
Если интернет не позволяет передать обновление через облако или FTP, мы применим метод «ручного» обновления. Это гарантированный способ привести версии баз к единому знаменателю.
1cv8.cf)..cf, узел все равно будет считать, что он ожидает подтверждения от центра. После ручного обновления конфигурации обязательно нужно успешно выполнить один цикл синхронизации, чтобы номера сообщений в ПланыОбмена выровнялись.Рассмотрим ситуацию, когда в попытках починить базу узел был «отвязан» от РИБ (командой УстановитьГлавныйУзел(Неопределено)). Чтобы вернуть его в состав распределенной базы без создания начального образа (что долго и трудно при плохом интернете), воспользуемся встроенным языком 1С.
Разберем алгоритм действий по шагам. Нам понадобится внешняя обработка или консоль кода, чтобы выполнить следующие команды:
// Сначала определим ссылку на узел, который является центральным в нашем плане обмена
ПланОбменаСсылка = ПланыОбмена.Розница.НайтиПоКоду("ЦБ"); // "ЦБ" - код вашей центральной базы
// Установим этот узел как главный для текущей базы
ПланыОбмена.УстановитьГлавныйУзел(ПланОбменаСсылка);
Внимание: Перед выполнением этой операции убедитесь, что версия конфигурации в подчиненном узле байт в байт совпадает с конфигурацией в центре. Если версии будут отличаться, база выдаст критическую ошибку при попытке обмена.
После ручных манипуляций часто происходит рассинхронизация счетчиков. Центральная база думает, что отправила сообщение №150, а подчиненная ожидает №148. В этом случае обмен не начнется. Проанализируем ситуацию через монитор синхронизации данных — решается через сравнение данных и поиск расхождений в 1С.
Нам необходимо сбросить или отредактировать номера принятых и отправленных сообщений. Посмотрим на программный способ корректировки:
ОбъектУзла = ПланОбменаСсылка.ПолучитьОбъект();
ОбъектУзла.НомерОтправленного = 0;
ОбъектУзла.НомерПринятого = 0;
ОбъектУзла.Записать();
После обнуления номеров, первый обмен будет длиться дольше обычного, так как система попытается сопоставить данные, но это позволит «протолкнуть» зависшие пакеты.
Посмотрим, как оптимизировать процесс доставки данных, если интернет остается слабым. Разберем три эффективных метода:
FTP-серверы на базе Linux некорректно обрабатывают кириллицу. В настройках синхронизации в 1С обязательно установим флаг «Использовать транслитерацию имен файлов сообщений обмена». Это заменит русские буквы в именах файлов (например, «Сообщение_ЦБ_МГ») на латиницу, что исключит ошибки «файл не найден».Яндекс.Диска или Dropbox через установку приложения на сервер гораздо надежнее FTP. Приложение облачного диска само занимается докачкой файлов в фоновом режиме, а 1С просто работает с локальной папкой на диске.Если вы столкнулись с проблемой отсутствия доступа к FTP, установленного сторонними специалистами, проанализируем, как извлечь настройки. Пароли в 1С хранятся в защищенном виде, но настройки подключения часто можно найти в регистре сведений ПараметрыОбменаДанными или в самих узлах планов обмена. Если пароль не удается вытащить программно, проверьте конфигурационные файлы установленных FTP-клиентов (например, FileZilla), где пароли могут храниться в XML в открытом или легко расшифруемом виде.
Многих волнует вопрос: не пропадут ли чеки и документы, созданные на точке за те дни, пока РИБ не работал? — поможет автоматическое сравнение документов между двумя базами. Успокоим пользователей: данные не пропадут. Все созданные объекты в 1С помечаются для обмена (регистрируются на узле).
Проверим это через «Состав отправляемых данных» в мониторе синхронизации. Если по какой-то причине документы за период сбоя не стоят в очереди на отправку, выполним их ручную регистрацию — есть готовая обработка массовой регистрации объектов в планах обмена. Для этого выберем нужные документы (например, «Чеки ККМ» или «Отчеты о розничных продажах») и воспользуемся командой «Зарегистрировать изменения всех объектов выбранного типа».
Чтобы избежать повторения ситуации, придерживаемся следующих правил:
WinSCP), если встроенный FTP-клиент 1С постоянно выдает ошибки по таймауту..cf последнего релиза центральной базы.Таким образом, мы выяснили, что даже при полном «отвале» РИБ и невозможности передачи данных через интернет, систему можно восстановить программными средствами 1С, сохранив всю историю продаж и целостность конфигурации.