PostgreSQL для 1С: репликация и автоматический failover в офисе на 50 рабочих мест

Привет! Меня зовут Семёнов Евгений Сергеевич, и вот уже 15 лет я погружён в мир корпоративных IT-инфраструктур в Москве и Подмосковье. Сегодня я хочу подробно разобрать один из своих любимых проектов 2025 года — мы тогда построили отказоустойчивую пару серверов PostgreSQL специально под 1С:Бухгалтерия и 1С:ЗУП для одной производственной компании на 45 рабочих мест. Я расскажу вам, почему мы в итоге отказались от MS SQL Server в пользу PostgreSQL, как выстраивали репликацию, что удалось собрать идеально, а что, признаюсь, стоило нам пары бессонных ночей. Все цифры, конфиги и, конечно же, бюджет — всё это вы найдёте дальше.

Кто заказчик и что было до нас

Наш клиент — крупный производитель мебельной фурнитуры из Подмосковья. Когда они впервые обратились к нам, в их офисе было 45 рабочих мест, плюс 12 человек в цеху работали через терминальный сервер, и ещё 6 удалёнщиков подключались по VPN. Для своей работы они использовали 1С:Бухгалтерия 8.3 (КОРП), 1С:ЗУП 3.1 и 1С:УНФ, которая отвечала за оперативный учёт производства. Объёмы баз данных были следующие: 78 ГБ для бухгалтерии, 14 ГБ для ЗУП и 22 ГБ для УНФ. В пиковые моменты число активных сеансов доходило до 38–42.

До нашего прихода вся их IT-система работала на одном-единственном сервере HP ProLiant DL380 Gen9, где стояли MS SQL Server 2014 Standard и 1С:Сервер предприятия. И тут, знаете, было сразу две главные проблемы. Во-первых, SQL Server морально устарел, да и лицензия на него истёкла ещё в 2023 году. А во-вторых, этот сервер представлял собой одну-единственную точку отказа. Стоило ему упасть, и весь офис вставал на полдня, потому что развёртывание бэкапа занимало целую вечность, а резервного железа просто не было. В 2024 году такое, к сожалению, уже случилось: 6 часов простоя, и, по подсчётам руководителя, это вылилось примерно в 380 тыс. руб. потерь.

Почему PostgreSQL, а не продление MS SQL

Мы сели и прикинули три возможных сценария: продлить лицензию на MS SQL Server 2019 Standard, перейти на PostgreSQL или уйти в облако 1С:Фреш. Облачный вариант отпал сразу, мы даже не стали его серьёзно рассматривать. Причина проста: огромный объём их баз и необходимость интеграции с производственным оборудованием. А вот когда мы стали сравнивать MS SQL и PostgreSQL, цифры буквально заговорили сами за себя:

Представьте, экономия на одних только лицензиях составила около 960 тыс. руб. сразу! Плюс мы полностью сняли риск, связанный с санкциями. Что касается производительности, наш опыт с другими клиентами показывает, что Postgres Pro для 1С на сравнимом железе держится на уровне MS SQL ±10 %. Для офиса, где работает 50 пользователей, такая разница вообще незаметна.

Архитектура решения

Мы разработали схему, состоящую из двух физических серверов, которые соединили отдельной 10G-линией специально для репликации. Вдобавок, на офисном гипервизоре мы развернули виртуалку-арбитр — она нужна для кворума при failover. Чтобы обеспечить максимальную надёжность, серверы мы разместили в двух независимых стойках в серверной клиента, причём каждый получил свой собственный UPS и отдельную электролинию.

Спецификация серверов pg-1c-prod-01 и pg-1c-prod-02:

• HP ProLiant DL380 Gen10 (ребилд из складского запаса клиента)
• 2 × Intel Xeon Gold 6230 (20 ядер каждый, 40 потоков)
• 192 ГБ DDR4 ECC RAM
• 2 × 960 ГБ NVMe Samsung PM983 в RAID1 (для ОС и WAL)
• 4 × 1.92 ТБ SSD Intel D3-S4610 в RAID10 (для PGDATA)
• 2 × 10GbE для репликации (прямое соединение DAC-кабелем)
• 2 × 1GbE для клиентских подключений

Операционную систему мы выбрали Astra Linux 1.7 SE — это было требование заказчика, связанное с импортозамещением. В качестве СУБД использовали Postgres Pro Standard 16 для 1С (это, кстати, бесплатная сборка). А 1С:Сервер 8.3.24 мы развернули отдельно на двух нодах, которые работают в режиме active-passive через keepalived с виртуальным IP.

Настройка streaming replication: пошагово

Я не буду переписывать сюда всю документацию по PostgreSQL, она открыта и, надо сказать, очень хороша. Вместо этого я хочу показать вам только те моменты, которые критичны именно для 1С и о которых, как показывает практика, чаще всего забывают.

На primary-сервере (pg-1c-prod-01) в postgresql.conf мы выставили:

wal_level = replica
max_wal_senders = 5
max_replication_slots = 5
wal_keep_size = 8GB
hot_standby = on
synchronous_commit = on
synchronous_standby_names = 'pg-1c-prod-02'
shared_buffers = 48GB
effective_cache_size = 144GB
work_mem = 64MB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
random_page_cost = 1.1
default_statistics_target = 200
max_connections = 200

Ключевой момент — synchronous_commit = on с явным указанием реплики. Это значит, что транзакция 1С получает подтверждение только после того, как WAL-запись физически приехала на реплику. Латентность по 10G-линку — менее 1 мс, поэтому замедления для пользователей 1С нет, зато при выходе primary из строя мы не теряем ни одной транзакции. Для бухгалтерии это критично.

А в pg_hba.conf добавили строку под репликацию:

host    replication     repl_user    10.30.0.2/32    scram-sha-256

На реплике (pg-1c-prod-02) сделали базовую копию через pg_basebackup и настроили standby-режим с физическим replication slot. Слот гарантирует, что primary не удалит WAL-сегменты, пока их не получит реплика — без этого при перезагрузке реплики мы могли получить «отвал» и пришлось бы полностью переинициализировать.

Автоматический failover: keepalived + скрипт

Для офиса на 45 РМ мы сознательно решили не тащить Patroni + etcd. Это, на мой взгляд, был бы явный перебор: пришлось бы разворачивать ещё три виртуалки etcd, настраивать дополнительный мониторинг, да и обучать админа клиента всему этому. Вместо такого усложнения мы взяли проверенную связку: keepalived (для виртуального IP) и наш кастомный bash-скрипт для переключения режима.

Логика работы такая:

• Виртуальный IP 10.30.0.10 поднят на primary, клиенты 1С подключаются к нему
• Keepalived каждые 2 секунды проверяет доступность PostgreSQL через pg_isready
• Если 3 проверки подряд провалились — VRRP переводит VIP на реплику
• На реплике скрипт promote_standby.sh вызывает pg_ctl promote и перезапускает 1С:Сервер
• Уведомление в Telegram-канал админов и на e-mail руководителя

С момента падения primary до того, как пользователи снова смогут зайти в 1С, проходит всего 38–55 секунд. А дальше админ получает чёткие инструкции, что делать с восстановленным primary — его нужно вернуть в строй уже как реплику, используя обратную репликацию.

Особенности именно для 1С

Знаете, 1С довольно капризна к настройкам PostgreSQL. Вот что обязательно нужно сделать, и о чём, к сожалению, регулярно забывают:

• Расширение online_analyze. Без него после массовой загрузки документов планировщик запросов 1С работает с устаревшей статистикой, и формирование оборотно-сальдовой ведомости из 5 секунд превращается в 90 секунд.
• Расширение plantuner. Позволяет фиксировать план выполнения для проблемных запросов 1С — без него 1С иногда уходит в seqscan на огромной таблице регистров.
• standard_conforming_strings = off. Жёсткое требование 1С, без этого регистры не читаются.
• escape_string_warning = off. Иначе журнал технологии заваливается warning'ами.
• fsync = on. Никогда не отключать ради «ускорения», как любят советовать в интернете. Один сбой питания — и база восстановлению не подлежит.

Параметры памяти под нашу нагрузку (192 ГБ RAM, базы 78+14+22 ГБ):

• shared_buffers = 48GB — четверть RAM, классическая рекомендация
• effective_cache_size = 144GB — три четверти RAM, говорим планировщику, что данные кэшированы
• work_mem = 64MB — на 200 соединений и тяжёлые отчёты 1С
• temp_buffers = 256MB — 1С активно использует временные таблицы

Бэкапы: репликация — это не бэкап

Очень часто встречающееся заблуждение звучит так: «У нас же есть реплика, зачем нам бэкапы?» Но это опасное заблуждение! Реплика, конечно, спасёт вас от физической смерти железа, но она абсолютно бессильна против логических ошибок. Представьте: бухгалтер случайно удалил документы за целый год, кривая обработка убила справочник, или, что ещё хуже, шифровальщик зашифровал базу. Любое такое изменение мгновенно уезжает на standby — и вот вы уже без данных сразу на обоих серверах.

Поэтому параллельно у нас работает:

• pg_basebackup ежедневно в 02:00 на отдельный NAS Synology RS1221+ (хранение 14 дней)
• pg_dump логический бэкап еженедельно по воскресеньям (хранение 12 недель)
• Раз в месяц копия архива на внешний USB-диск, который живёт в сейфе у руководителя
• Раз в квартал — тестовое разворачивание бэкапа на отдельной ВМ с проверкой целостности базы 1С через Тестирование и исправление

Без последнего пункта ваш бэкап — это настоящий кот Шрёдингера: пока не попробуешь восстановить, никогда не узнаешь, рабочий он или нет. А это огромный риск.

Мониторинг и оповещения

На обоих серверах стоит Zabbix-агент, который следит за:

• Статус репликации (отставание реплики в байтах и секундах)
• Работоспособность процессов postgres и rphost (1С:Сервер)
• Заполнение дисков (предупреждение — 80 %, критическое — 90 %)
• Количество активных сеансов 1С через журнал регистрации
• Длительность долгих запросов (более 30 секунд)
• Состояние RAID-массивов и температуру дисков через smartctl

Все триггеры круглосуточно сыплются в Telegram-чат дежурного инженера. А если ситуация критическая, то они дублируются звонком через нашего бота. Согласно SLA для этой инфраструктуры, мы гарантируем реакцию в течение 15 минут в любое время суток.

Бюджет проекта и срок окупаемости

Чтобы мои слова не были голословными, вот вам честный расклад по деньгам, которые наш клиент реально потратил весной 2025 года:

А теперь сравните это с одним-единственным инцидентом 2024 года, который обошёлся клиенту в 380 тыс. руб. Или с альтернативой — покупкой MS SQL Standard на 4 ядра плюс Software Assurance под AlwaysOn, а это, между прочим, около 1,4 млн руб. только за лицензии. В итоге, окупаемость нашей схемы составляет 14 месяцев по самой осторожной оценке. А по факту — она окупится сразу же после первого предотвращённого простоя. По-моему, это отличный результат!

Грабли, на которые мы наступили

Не буду делать вид, что всё прошло как по маслу. Вот что было больно:

• Astra Linux + Postgres Pro. Из-за SE-Linux-подобного механизма Astra пришлось вручную править контексты безопасности для каталогов PGDATA и pg_wal. Потратили половину субботы.
• Большие транзакции 1С:Закрытие месяца. На реплике временно отставание росло до 4 ГБ WAL. Решили увеличением wal_keep_size до 16 ГБ и переходом на slot-based replication.
• 1С:Сервер не сразу подхватывал смену primary. Пришлось дописать в promote_standby.sh принудительный рестарт rphost после промоушена реплики.
• VPN-пользователи теряли соединение при failover. Решилось настройкой keepalive в клиенте 1С на 30 секунд вместо стандартных 600.

Что получил клиент по итогу

За год эксплуатации (с мая 2025 по апрель 2026) у клиента было:

• Один реальный failover в августе 2025 из-за выхода из строя контроллера дисков на primary. Простой пользователей — 47 секунд, потерь данных — 0.
• Два плановых переключения для замены прошивки на дисках. Пользователи замены не заметили.
• Скорость работы 1С выросла на 18 % по сравнению с предыдущим MS SQL за счёт более свежего железа и грамотной настройки.
• Стоимость обслуживания инфраструктуры баз данных снизилась с 2.1 млн руб./год (поддержка MS SQL + риск) до 480 тыс. руб./год.

FAQ — частые вопросы по PostgreSQL для 1С

Зачем нужна репликация PostgreSQL для 1С в небольшом офисе?

Главная причина — деньги. При 45 пользователях час простоя сервера 1С в активный день стоит около 60–90 тыс. руб. упущенной выручки и зарплат. Реплика снижает RTO с 4–6 часов (восстановление из бэкапа) до 5–10 минут (переключение). Окупается за один инцидент.

Сколько стоит схема с репликацией для офиса до 50 РМ?

Базовый комплект — 2 сервера на 32 ГБ ОЗУ и SSD NVMe 2x960 ГБ в RAID1 — обходится в 380–450 тыс. руб. оборудования плюс 65–90 тыс. руб. работ по настройке. Лицензии PostgreSQL для 1С — бесплатно (мы используем сборку Postgres Pro Standard 16 для 1С).

Можно ли обойтись одним сервером и просто ежедневным бэкапом?

Можно, но это плохой выбор для бизнеса с активной работой в 1С. При сбое HDD на сервере без репликации восстановление из бэкапа двухчасовой давности занимает от 3 до 8 часов и теряет работу за прошедшие 2 часа. Реплика устраняет обе проблемы.

Что выбрать для PostgreSQL под 1С: ванильный PostgreSQL или Postgres Pro?

Для 1С используйте только Postgres Pro 1C (бесплатная сборка от Postgres Professional, специально патченная под 1С) или ванильный PostgreSQL с патчами 1С. Чистый PostgreSQL без патчей в 1С работает с грубыми ошибками при сложных запросах.

Как тестировать failover, чтобы не словить сюрприз в продакшене?

Раз в квартал в выходной день в 8:00 мы намеренно гасим primary-сервер. Засекаем время до восстановления работы 1С на реплике, проверяем, что не потерялось ни одной транзакции, отрабатываем переключение клиентов. Без таких учений первый реальный инцидент превращается в катастрофу.