Рассмотрим классическую критическую ситуацию, с которой сталкиваются многие компании при попытке сэкономить на ИТ-инфраструктуре: связка 1С:Предприятие 8.3 и СУБД PostgreSQL на операционной системе Windows с использованием десктопного (потребительского) железа. В процессе интенсивных транзакционных нагрузок — таких как групповое перепроведение документов — система дает сбой, пользователи вылетают из базы, а после перезапуска обнаруживается частичная или полная потеря данных (например, «исчезновение» документов за определенный период времени).
В этой статье мы подробно проанализируем, почему происходят подобные сбои, выясним физические причины разрушения таблиц СУБД, сравним поведение PostgreSQL и MS SQL Server в экстремальных условиях, а также составим пошаговый план по предотвращению таких аварий в будущем.
В рассматриваемом сценарии СУБД PostgreSQL 10 функционировала на ОС Windows Server 2008 R2. Аппаратная конфигурация состояла из процессора Core i7-4770, 32 ГБ оперативной памяти и потребительских SSD-накопителей Intel SSD 530 (модель ssdcd2bw120a4), объединенных в программный RAID-1 средствами операционной системы Windows (динамические диски).
Во время монопольного перепроведения документов под учетной записью администратора произошел вылет процессов СУБД и сервера приложений 1С. После перезапуска службы в журнале документов пропали записи за несколько дней. СУБД при этом в логах начала сообщать об отсутствии определенных таблиц (relation does not exist) или повреждении структуры страниц данных. Разберем по шагам скрытые аппаратные причины этого сбоя:
Среди ИТ-специалистов бытует мнение, что Microsoft SQL Server работает стабильнее в «плохих» условиях. Проанализируем, почему это действительно так, и в чем кроется разница в архитектуре СУБД:
FILE_FLAG_WRITE_THROUGH), которые принудительно заставляют дисковые контроллеры сбрасывать кэш на физический носитель. PostgreSQL на Windows работает через слой эмуляции POSIX-совместимых вызовов, что снижает эффективность контроля дискового кэша.CHECKSUM). При обнаружении поврежденной страницы MS SQL часто способен изолировать сбойную область данных (или конкретную транзакцию), позволяя остальной базе функционировать. PostgreSQL при обнаружении повреждения критически важной страницы системного каталога или индексов может аварийно завершить работу всей службы во избежание дальнейшего повреждения данных.Помимо аппаратных факторов, важнейшим триггером разрушения баз данных на PostgreSQL является использование механизма динамического обновления конфигурации 1С (так называемого «демонического» обновления). Проанализируем механизм этого процесса:
При выполнении динамического обновления платформа 1С не останавливает работу активных пользователей. Вместо этого в СУБД создаются дублирующие структуры таблиц метаданных с новыми уникальными идентификаторами. Новые сеансы начинают работать с новыми таблицами, а старые — дорабатывают со старыми.
В PostgreSQL этот процесс порождает огромное количество блокировок и резкий рост версий строк (механизм MVCC). Если в этот момент выполняется массовая транзакционная нагрузка (перепроведение документов), планировщик PostgreSQL сталкивается с конфликтами схем данных. В случае аварийного закрытия сеанса или падения службы транзакция фиксации новой конфигурации зависает. База данных переходит в состояние логической несогласованности, при которой платформа 1С больше не может сопоставить объекты метаданных с физическими таблицами PostgreSQL, выдавая критические ошибки отсутствия таблиц.
Если вы приняли решение не покупать дорогостоящие лицензии MS SQL Server Standard (которые для 30 пользователей могут стоить дороже нового сервера), необходимо полностью перестроить подход к инфраструктуре и администрированию PostgreSQL. Разберем по шагам обязательные действия.
Для PostgreSQL операционная система Linux является родной и наиболее оптимизированной средой обитания. Настоятельно рекомендуем развернуть СУБД на дистрибутивах Linux (например, Ubuntu Server, Rocky Linux или Astra Linux). Это даст следующие преимущества:
Запомните золотое правило: СУБД PostgreSQL не должна работать на десктопном железе в промышленной среде. Выполним модернизацию:
mdadm (уровня RAID-1 или RAID-10) либо установим выделенный аппаратный RAID-контроллер с батарейкой резервного питания (BBU или SuperCap).Ошибки в конфигурационном файле postgresql.conf могут быстро разрушить базу данных или снизить производительность до нуля. Проанализируем правильные параметры конфигурации для сервера с 32 ГБ ОЗУ и SSD-накопителями:
# Основные параметры производительности и безопасности
shared_buffers = 8GB # 25% от общего объема ОЗУ (32GB)
effective_cache_size = 24GB # Около 75% от общего объема ОЗУ
work_mem = 64MB # Лимит памяти для одной операции сортировки
maintenance_work_mem = 2GB # Память для создания индексов и очистки
max_locks_per_transaction = 256 # Важно для тяжелых запросов 1С
# Настройки дисковой подсистемы под SSD
random_page_cost = 1.1 # Оптимально для SSD (по умолчанию 4.0 для HDD)
effective_io_concurrency = 200 # Позволяет эффективно использовать параллельный ввод-вывод SSD
# Безопасность записи транзакций (КРИТИЧЕСКИ ВАЖНО)
fsync = on # КАТЕГОРИЧЕСКИ ВКЛЮЧЕНО! Запрещено выключать в продакшене.
synchronous_commit = on # Гарантирует фиксацию транзакций на диске перед ответом клиенту
checkpoint_completion_target = 0.9 # Сглаживает нагрузку при записи контрольных точек
checkpoint_timeout = 15min # Оптимальный интервал между контрольными точками
max_wal_size = 16GB
min_wal_size = 2GB
Обратите внимание: предложенная в обсуждениях настройка random_page_cost = 0.1 является ошибочной и экстремально заниженной. Она заставляет планировщик игнорировать последовательное чтение таблиц, отдавая избыточное предпочтение индексам даже там, где это неэффективно, что приводит к перерасходу оперативной памяти.
Для предотвращения потери данных в случае сбоя настроим механизм архивирования файлов журнала предзаписи (Write-Ahead Logging). Этот механизм позволяет восстановить базу данных на любую секунду в прошлом (технология PITR — Point-In-Time Recovery).
Рассмотрим пример настройки непрерывного копирования WAL-файлов. Для этого в конфигурационном файле postgresql.conf необходимо задать следующие параметры:
# Включаем режим архивирования
wal_level = replica
archive_mode = on
# Команда для копирования заполненных WAL-файлов в защищенное хранилище
# Пример для операционной системы Linux:
archive_command = 'test ! -f /mnt/backup/wal_archive/%f && cp %p /mnt/backup/wal_archive/%f'
# Пример для операционной системы Windows (если СУБД временно остается на ней):
# archive_command = 'copy "%p" "D:\\postgresql\\wal_archive\\%f"'
При такой настройке каждые 16 МБ записанных изменений автоматически копируются на выделенный диск резервного копирования. Если база данных будет повреждена, мы сможем взять вчерашнюю физическую копию базы данных (базовый бэкап, сделанный через pg_basebackup), положить ее в чистый каталог, создать файл конфигурации восстановления и запустить процесс наката WAL-файлов до секунды, предшествующей аварии.
Для обеспечения стабильности работы базы данных 1С на СУБД PostgreSQL необходимо придерживаться жестких административных правил:
VACUUM (очистка устаревших версий строк) и ANALYZE (обновление статистики планировщика запросов). Для высоконагруженных таблиц рекомендуется настроить более агрессивный автовакуум (autovacuum).Выбор между покупкой коммерческой СУБД MS SQL Server и доработкой инфраструктуры под бесплатный PostgreSQL сводится к расчету совокупной стоимости владения (TCO):