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

Разберу один из проектов 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С на реплике, проверяем, что не потерялось ни одной транзакции, отрабатываем переключение клиентов. Без таких учений первый реальный инцидент превращается в катастрофу.