Чёрный пояс 1С. Две новые задачи senior-уровня: отказоустойчивость кластера с Дата акселератором, управляемые блокировки и лимит индекса Oracle

7 сентября 2026 · infolimp.ru · Чёрный пояс 1С

В пул токен-платформы добавлены две новые задачи уровня Senior/Architect - обе из практики холдингов с распределённой инфраструктурой на PostgreSQL. Ниже - анонс обеих и полный разбор первой: как посчитать отказоустойчивость кластера и изолировать Дата акселератор от транзакционной нагрузки, не поймав деградацию СУБД при первом же сбое.

Две новые задачи

Разбор: отказоустойчивость кластера и Дата акселератор

Условие. В центральном офисе холдинга развёрнут кластер серверов 1С на трёх физических машинах (условно SRV1, SRV2, SRV3), СУБД - PostgreSQL 15. Нагрузка неравномерна: в течение дня идёт массовый ввод первичных документов, а параллельно топ-менеджмент формирует тяжёлые аналитические отчёты по продажам. Задача - изолировать транзакционную нагрузку от аналитической, поднять Дата акселератор (In-Memory DB) и настроить репликацию изменений на PostgreSQL так, чтобы отчёты не замедляли ввод документов ни на миллисекунду.

1. Сколько центральных серверов нужно на самом деле

Формула простая и её достаточно, чтобы не спорить с заказчиком о «лишнем» сервере: Количество центральных серверов = Уровень отказоустойчивости + 1. При уровне отказоустойчивости 1 в кластере должно быть минимум 2 центральных сервера - SRV1 и SRV2 в этом сценарии.

Отдельно - параметры проверки соединений между процессами кластера: период проверки не менее 1000 мс (рекомендуется 1000 мс период и 5000 мс таймаут), и это значение обязано быть идентичным на всех серверах кластера. На клиентских ПК при этом отключаются любые энергосберегающие режимы (Sleep, Standby, Hibernate) - иначе кластер честно решит, что сессия оборвалась, а пользователь просто ушёл на обед с открытым ноутбуком.

2. Требования назначения функциональности: как не пустить аналитику на транзакционные серверы

SRV3 в этом сценарии выделяется строго под Дата акселератор и фоновые задания построения отчётов - и ни под что больше:

• ☐ На SRV3: правило «Сервис Дата акселератора» → «Назначать»
• ☐ На SRV3: правило «Любой объект требования» → «Не назначать» (изоляция прочих сервисов)
• ☐ На SRV1 и SRV2: правило «Сервис Дата акселератора» → «Не назначать»

Без явного запрещающего правила на SRV1/SRV2 платформа рано или поздно развернёт процесс акселератора именно там, где он будет конкурировать с интерактивными сеансами за память - и найти причину внезапных тормозов в проде станет отдельным квестом.

3. Репликация на PostgreSQL 15: логическое декодирование и fsync

Для стандартной репликации изменений (Версия 2) на PostgreSQL 15 нужен параметр wal_level = logical в postgresql.conf, перезапуск СУБД и включение Версии 2 в настройках копирования на стороне 1С.

Отдельный вопрос - fsync. По умолчанию он включён ради транзакционной консистентности, но это стоит производительности записи. Безопасно отключать его можно только на аппаратной базе, которая переживёт внезапное отключение питания без потери данных: кеширующие RAID-контроллеры с энергонезависимой кеш-памятью плюс UPS. Без этой связки отключение fsync - это не оптимизация, а прямая дорога к битой реплике после первого же скачка напряжения. Дополнительно на реплицируемых таблицах при интенсивной записи/удалении стоит регулярно планировать REINDEX (или VACUUM) - иначе индексы деградируют быстрее, чем кажется на бумаге.

4. Программное управление составом копии базы

// Добавление справочника в состав копии базы данных
Копия = КопииБазыДанных.Найти("TestCopy");
ЭлементКопии = Копия.Состав.Добавить(Метаданные.Справочники.Номенклатура);

// Явное указание использования только реквизита "Артикул"
ПолеКопии = ЭлементКопии.Поля.Найти("Артикул");
ПолеКопии.Использование = ИспользованиеПоляЭлементаСоставаКопииБазыДанных.Использовать;

Копия.Записать();
КопииБазыДанных.Обновить(Копия, Ложь); // Инициализация обновления состава

Требования к железу под сам Дата акселератор: 64-разрядная ОС и платформа, Java 1.8+, лицензия уровня КОРП для запуска нескольких процессов акселератора в кластере, минимум 64 Гбайт ОЗУ (комфортно - от 512 Гбайт). И ключевое архитектурное решение при проектировании отказоустойчивости: хранить копию акселератора «только в памяти» - значит после перезапуска сервера ждать долгого начального обновления из СУБД с нуля; хранить «в памяти и на диске» - значит платформа кеширует данные локально и восстанавливается кратно быстрее после аварии.

О конвейере

Ежедневно в пул токен-платформы добавляются новые задачи повышенной сложности. Темы - из внутреннего корпуса материалов редакции: интеграции с внешними системами и ИИ-сервисами, администрирование кластера и лицензирование, платформенная безопасность и профили доступа. Каждый седьмой анонс сопровождается полным разбором с примером решения и диалогом с AI-помощником nopikreport.com - как в этом выпуске.