PostgreSQL для 1С: совместимость, установка и базовая настройка

PostgreSQL — одна из поддерживаемых систем управления базами данных для клиент-серверного варианта «1С:Предприятия». Ее можно использовать вместо Microsoft SQL Server, если организации требуется серверная база 1С без привязки к СУБД Microsoft, планируется Linux-инфраструктура или уже есть специалисты по PostgreSQL.

При этом установка обычного пакета PostgreSQL из репозитория операционной системы не гарантирует совместимость с конкретной версией платформы 1С. Фирма «1С» публикует перечень поддерживаемых СУБД, готовые сборки PostgreSQL с необходимыми изменениями и требования к операционным системам.

Еще одна распространенная ошибка — скопировать готовый файл postgresql.conf с другого сервера. Параметры памяти, подключений и обслуживания зависят от объема ОЗУ, количества пользователей, размеров баз, характера запросов и того, размещаются ли PostgreSQL и сервер 1С на одном компьютере.

Поэтому подготовка начинается не с изменения shared_buffers и work_mem, а с проверки совместимости, выбора архитектуры, оценки ресурсов и создания резервной копии. Только после запуска тестовой базы можно собирать показатели и корректировать параметры под фактическую нагрузку.

Когда PostgreSQL подходит для серверной 1С

В клиент-серверном варианте данные хранятся в СУБД, а кластер серверов 1С выполняет прикладную логику, обслуживает сеансы и передает запросы к базе данных.

                Клиенты 1С
                    │
                    ▼
          Кластер серверов 1С
        ragent / rmngr / rphost
                    │
                    │ запросы к СУБД
                    ▼
                PostgreSQL
                    │
                    ▼
        Файлы базы, WAL и журналы
                    │
                    ▼
          Резервное хранилище

PostgreSQL можно рассматривать в следующих сценариях:

• клиент-серверная база 1С развертывается на Linux;
• организация хочет использовать поддерживаемую СУБД без лицензий Microsoft SQL Server;
• в компании уже есть администраторы PostgreSQL;
• нужно разделить сервер 1С и сервер базы данных;
• требуется несколько информационных баз на одном сервере СУБД;
• планируется миграция файловой базы в клиент-серверный вариант;
• производительность файлового режима перестала соответствовать нагрузке.

PostgreSQL или Microsoft SQL Server

Обе СУБД поддерживаются платформой 1С, но отличаются лицензированием, инструментами администрирования и требованиями к компетенциям команды.

Выбор нельзя делать только по стоимости лицензии. Нужно учитывать опыт администраторов, существующую инфраструктуру, требования конфигурации, резервное копирование, мониторинг и возможное время восстановления.

Как проверить совместимость PostgreSQL и платформы 1С

До загрузки дистрибутива необходимо сопоставить три компонента:

• версию платформы «1С:Предприятие»;
• версию и редакцию PostgreSQL;
• операционную систему сервера базы данных.

Фирма «1С» ведет актуальный перечень поддерживаемых СУБД и отдельно публикует список операционных систем для них. В перечне могут присутствовать:

• сборки PostgreSQL с изменениями от фирмы «1С»;
• Postgres Pro;
• Tantor;
• другие сертифицированные или поддерживаемые решения;
• ограничения по версии платформы и операционной системе.

Конкретные номера версий быстро меняются, поэтому их нельзя выбирать по старой инструкции или по номеру СУБД на другом сервере.

Почему обычная сборка PostgreSQL может не подойти

Фирма «1С» публикует собственные сборки PostgreSQL с изменениями, предназначенными для совместимости и работы в типовых сценариях платформы. Кроме того, в актуальном перечне могут присутствовать сторонние продукты, прошедшие необходимую проверку.

Использование неподтвержденной комбинации создает несколько рисков:

• ошибки при создании информационной базы;
• проблемы при обновлении конфигурации;
• неожиданное поведение запросов;
• ограничения при обращении в техническую поддержку;
• несовместимость после обновления платформы;
• необходимость срочной замены СУБД в рабочей системе.

Что зафиксировать перед установкой

Как спроектировать серверную схему

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

Все компоненты на одном сервере

На одном VPS или физическом сервере могут работать:

• кластер серверов 1С;
• PostgreSQL;
• клиентские сеансы через удаленный рабочий стол;
• фоновые задания;
• дополнительные службы.

Схема проще в администрировании и не требует отдельного сетевого соединения между 1С и СУБД. Но все компоненты конкурируют за общие CPU, память и диски.

При совмещенном размещении нельзя отдавать PostgreSQL почти всю оперативную память. Необходимо оставить ресурсы:

• операционной системе;
• процессам rphost;
• терминальным сеансам;
• антивирусу и мониторингу;
• резервному копированию;
• кэшу файловой системы.

PostgreSQL на отдельном сервере

Разделение позволяет независимо масштабировать сервер 1С и СУБД, но добавляет сетевую зависимость.

Необходимо обеспечить:

• стабильный канал с низкой задержкой;
• ограниченный доступ к порту PostgreSQL;
• синхронизацию времени;
• раздельный мониторинг узлов;
• резервное копирование базы;
• план действий при недоступности сети;
• достаточную пропускную способность между серверами.

Размещать сервер 1С и PostgreSQL в разных географических площадках через обычный интернет обычно нежелательно. Даже при достаточной пропускной способности задержка влияет на большое количество коротких обращений к СУБД.

Требования к дисковой подсистеме

Для рабочей базы важны не только объем и последовательная скорость, но и задержка операций ввода-вывода.

На дисках размещаются:

• основные файлы базы;
• индексы;
• WAL;
• временные файлы запросов;
• журналы PostgreSQL;
• резервные копии, если они временно формируются локально.

Для рабочей клиент-серверной базы следует использовать SSD или NVMe с предсказуемой производительностью. Размещение PostgreSQL на медленном сетевом диске может привести к задержкам, которые не устраняются увеличением памяти.

Оценка ресурсов

Универсального соотношения «число пользователей — объем памяти» не существует. Нагрузка зависит от конфигурации и характера операций.

При оценке учитываются:

• число одновременных пользователей;
• количество информационных баз;
• размеры активных данных;
• сложность отчетов;
• фоновые и регламентные задания;
• обмены с внешними системами;
• терминальные сеансы;
• темп роста базы;
• окно резервного копирования;
• требования к восстановлению.

Установка PostgreSQL и подготовка доступа

Порядок установки зависит от выбранной сборки и операционной системы. Использовать нужно документацию поставщика конкретной СУБД, а не универсальную команду из инструкции для другого дистрибутива.

Безопасная последовательность установки

1. Проверить совместимость версий.
2. Скачать дистрибутив из официального источника.
3. Проверить контрольную сумму или подпись пакета, если она публикуется.
4. Создать резервную копию сервера перед изменениями.
5. Установить необходимые зависимости.
6. Установить сервер PostgreSQL и клиентские утилиты.
7. Инициализировать кластер базы данных штатным способом поставщика.
8. Проверить состояние службы.
9. Зафиксировать расположение файлов конфигурации и данных.
10. Создать отдельную учетную запись СУБД для 1С.
11. Ограничить сетевой доступ.
12. Подключить тестовую информационную базу.

Проверка установленной версии

Версия клиентской утилиты:

psql --version

Версия сервера после подключения:

SELECT version();

Отдельно нужно проверить, что используется именно запланированная сборка, а не другой PostgreSQL, оставшийся в системных репозиториях.

Расположение каталога данных:

SHOW data_directory;

Основного файла конфигурации:

SHOW config_file;

Файла правил клиентской аутентификации:

SHOW hba_file;

Создание пользователя для 1С

Для информационных баз не следует использовать административную роль postgres. Создается отдельная учетная запись с паролем.

Пример из консоли psql:

CREATE ROLE user1c
    WITH LOGIN
    PASSWORD 'replace-with-a-strong-password'
    CREATEDB;

Право CREATEDB требуется, если сервер 1С должен самостоятельно создать новую информационную базу. После завершения первоначальной настройки состав прав можно пересмотреть с учетом принятого порядка администрирования.

Пароль необходимо:

• сгенерировать случайным способом;
• хранить в защищенном менеджере паролей;
• не передавать в открытой переписке;
• не использовать для системной учетной записи;
• не применять в других сервисах;
• менять по контролируемой процедуре.

Создавать базу вручную или через консоль 1С

Информационную базу можно создать при регистрации в кластере 1С, если выбранный пользователь СУБД имеет необходимые права. Это снижает риск ошибиться в параметрах кодировки и владельца.

Если база создается вручную, нужно использовать требования платформы и выбранной сборки PostgreSQL. Нельзя без проверки менять:

• кодировку;
• локаль;
• владельца;
• шаблон базы;
• параметры сортировки;
• расширения.

После создания вручную база регистрируется в кластере 1С без повторного создания физической базы данных.

Сетевой доступ

PostgreSQL по умолчанию может принимать только локальные подключения. Для отдельного сервера СУБД потребуется настроить адреса прослушивания и правила pg_hba.conf.

Проверить текущий адрес:

SHOW listen_addresses;

Порт:

SHOW port;

В pg_hba.conf следует разрешать только конкретный сервер 1С или доверенную подсеть. Упрощенный пример правила:

host    all    user1c    10.10.20.15/32    scram-sha-256

Здесь 10.10.20.15 — пример адреса сервера 1С. Его нужно заменить фактическим значением.

После изменения конфигурации следует проверить ее штатным способом выбранного дистрибутива и перечитать настройки или перезапустить службу, если это требуется для измененного параметра.

Проверка подключения

С сервера 1С можно проверить сетевую доступность порта:

nc -vz db-server.example.local 5432

Либо использовать клиент PostgreSQL:

psql \
    --host=db-server.example.local \
    --port=5432 \
    --username=user1c \
    --dbname=postgres

Если порт доступен, но авторизация завершается ошибкой, нужно проверить пользователя, пароль и правила pg_hba.conf. Если соединение не устанавливается, проверяются адрес прослушивания, firewall, маршрут и состояние службы.

Базовая настройка PostgreSQL для 1С

Начальные параметры должны соответствовать ресурсам конкретного сервера. Значения из чужого файла нельзя применять без расчета: многие параметры расходуют память не один раз на весь сервер, а для каждого процесса, запроса или операции.

Какие параметры требуют внимания

Почему опасно завышать work_mem

work_mem не является единым лимитом на все запросы. Один сложный запрос может одновременно выполнять несколько сортировок и хеш-операций, а таких запросов на сервере может быть много.

Упрощенно пиковое потребление зависит от:

• числа активных подключений;
• количества операций внутри каждого плана;
• параллельных работников;
• фоновых процессов;
• других служб на сервере.

Поэтому большое значение, которое безопасно на тестовой базе с одним пользователем, может привести к нехватке памяти в рабочее время.

Не отключать autovacuum

PostgreSQL использует многоверсионность. Обновленные и удаленные версии строк не исчезают физически сразу. Autovacuum очищает таблицы и обновляет статистику, необходимую планировщику запросов.

Отключение autovacuum может привести к:

• росту таблиц и индексов;
• ухудшению планов выполнения;
• увеличению объема резервных копий;
• дополнительной нагрузке на диски;
• риску проблем с идентификаторами транзакций;
• необходимости тяжелого ручного обслуживания.

Если autovacuum мешает рабочей нагрузке, нужно анализировать конкретные таблицы, частоту изменений и длительность операций, а не выключать механизм целиком.

Фиксация исходной конфигурации

Перед изменением необходимо сохранить текущие параметры:

SELECT name, setting, unit, source
FROM pg_settings
ORDER BY name;

Показать параметры, отличающиеся от значений по умолчанию:

SELECT name, setting, unit, source
FROM pg_settings
WHERE source <> 'default'
ORDER BY name;

Для каждого изменения следует записывать:

• старое значение;
• новое значение;
• причину;
• дату;
• ответственного;
• ожидаемый эффект;
• результаты после применения;
• способ возврата.

Журналирование медленных запросов

Для диагностики можно временно включить регистрацию запросов, превышающих выбранную продолжительность.

Проверить текущее значение:

SHOW log_min_duration_statement;

Порог выбирается по задаче и нагрузке. Слишком подробное журналирование на рабочей базе создает дополнительный I/O и быстро расходует место.

После сбора данных необходимо:

• сохранить нужный фрагмент журнала;
• проверить объем файлов;
• вернуть обычный уровень логирования;
• сопоставить запросы с действиями в 1С;
• не публиковать журналы с конфиденциальными данными.

Резервное копирование, обслуживание и мониторинг

Резервное копирование базы PostgreSQL должно быть настроено до ввода 1С в эксплуатацию. Копия каталога данных при работающей службе не всегда является согласованной резервной копией.

Варианты резервного копирования

Для небольшой базы может быть достаточно регулярного логического backup и копии сервера. Для крупной рабочей системы, где допустима минимальная потеря данных, требуется физическое резервирование и архивирование WAL.

Конкретную схему выбирают с учетом:

• размера базы;
• темпа изменений;
• допустимой потери данных;
• допустимого времени простоя;
• скорости хранилища;
• канала передачи;
• места для нескольких поколений;
• возможности тестового восстановления.

Копии должны храниться отдельно

Архивы нельзя хранить только на том же диске, где расположена рабочая база. Отказ диска, удаление VPS или компрометация администратора могут уничтожить данные и backup одновременно.

Минимальная схема включает:

• рабочую базу;
• локальную копию для быстрого восстановления, если она нужна;
• копию во внешнем хранилище;
• несколько точек восстановления;
• уведомления об ошибках;
• периодический тест восстановления.

Проверка восстановления

Факт создания файла не подтверждает работоспособность backup. Копию нужно периодически восстанавливать в отдельную тестовую базу.

После восстановления проверяются:

• целостность архива;
• наличие нужной точки по времени;
• доступ пользователя СУБД;
• регистрация базы в тестовом кластере 1С;
• запуск конфигурации;
• выполнение основных операций;
• время полного восстановления;
• достаточность инструкции.

Что контролировать в PostgreSQL

Мониторинг должен охватывать не только состояние службы.

Нужно контролировать:

• доступность PostgreSQL;
• число подключений;
• длительные запросы;
• ожидания и блокировки;
• объем базы и отдельных таблиц;
• рост WAL;
• работу autovacuum;
• временные файлы;
• частоту контрольных точек;
• ошибки в журналах;
• свободное место;
• задержку дисковой подсистемы;
• возраст последней успешной копии.

Текущие подключения:

SELECT datname, usename, state, count(*)
FROM pg_stat_activity
GROUP BY datname, usename, state
ORDER BY datname, usename, state;

Активные запросы:

SELECT pid,
       usename,
       datname,
       now() - query_start AS duration,
       wait_event_type,
       wait_event,
       query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY query_start;

Размеры баз:

SELECT datname,
       pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database
ORDER BY pg_database_size(datname) DESC;

Эти запросы помогают увидеть текущее состояние, но не заменяют постоянный мониторинг и накопление истории.

Типичные ошибки при развертывании PostgreSQL для 1С

Ошибка подключения к серверу баз данных

Если 1С не может создать или открыть информационную базу, проверка выполняется по уровням:

1. Работает ли служба PostgreSQL.
2. Прослушивается ли ожидаемый адрес и порт.
3. Разрешен ли порт в firewall.
4. Есть ли правило для сервера 1С в pg_hba.conf.
5. Правильно ли указаны сервер и порт.
6. Существует ли пользователь СУБД.
7. Верный ли пароль.
8. Есть ли права на создание или подключение к базе.
9. Совместима ли версия PostgreSQL.

PostgreSQL потребляет слишком много памяти

Нужно проверить не только shared_buffers, но и:

• work_mem;
• maintenance_work_mem;
• max_connections;
• число активных запросов;
• параллельные процессы;
• autovacuum workers;
• кэш операционной системы;
• потребление памяти процессами 1С.

На совмещенном сервере необходимо анализировать суммарное потребление PostgreSQL, кластера 1С, терминальных сеансов и операционной системы.

Быстро растет диск

Причинами могут быть:

• рост рабочей базы;
• накопление WAL;
• неработающее архивирование;
• длительная транзакция;
• реплика, которая не получает WAL;
• избыточные журналы;
• локальные резервные копии;
• неэффективная работа autovacuum;
• временные файлы больших запросов.

Удалять файлы из каталога PostgreSQL вручную нельзя. Сначала определяется их назначение и причина роста.

Заключение

PostgreSQL подходит для клиент-серверной 1С, если используется совместимая сборка, сервер обеспечен достаточными ресурсами, а в компании есть понятный порядок администрирования СУБД.

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

Параметры памяти, подключений, WAL и autovacuum настраиваются по ресурсам и фактической нагрузке. Использование универсального конфигурационного файла без расчета может ухудшить работу даже на производительном сервере.

До запуска рабочей базы необходимо настроить резервное копирование во внешнее хранилище, проверить восстановление и организовать мониторинг дисков, запросов, блокировок, autovacuum и возраста последнего backup.

Что почитать дальше

Для проектирования и диагностики серверной среды 1С будут полезны следующие материалы:

• Серверная инфраструктура 1С: как спроектировать рабочую схему — взаимодействие клиентов, кластера серверов 1С и СУБД.
• Какой сервер нужен для 1С:Бухгалтерии — какие ресурсы учитывать при выборе VPS и серверной архитектуры.
• Почему тормозит 1С на сервере — как разделить проблемы оборудования, СУБД и прикладного кода.
• Сетевые порты сервера 1С — какие соединения нужны между клиентами, кластером и PostgreSQL.

Когда стоит обратиться к специалистам

Тестовую базу можно развернуть самостоятельно, если администратор знаком с PostgreSQL, понимает правила сетевого доступа и использует официально поддерживаемую комбинацию версий. Перенос рабочей базы требует дополнительной подготовки и проверки восстановления.

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

Кратко

• PostgreSQL является одной из поддерживаемых СУБД для клиент-серверной 1С.
• Версию СУБД нужно выбирать по актуальной матрице совместимости фирмы «1С».
• Для информационных баз создается отдельный пользователь PostgreSQL.
• Порт СУБД открывается только серверу 1С и доверенным административным узлам.
• Параметры памяти нельзя переносить с другого сервера без расчета.
• Autovacuum не следует отключать для устранения временной нагрузки.
• Резервные копии должны храниться отдельно от рабочей базы.
• Работоспособность backup подтверждается тестовым восстановлением.