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.

До нашего прихода всё крутилось на одном сервере 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 (требование заказчика для импортозамещения), PostgreSQL — 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. Это избыточно: добавляет 3 виртуальные машины 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С на реплике, проверяем, что не потерялось ни одной транзакции, отрабатываем переключение клиентов. Без таких учений первый реальный инцидент превращается в катастрофу.