Применение механизма копии базы 1С в кластере Postgres Pro BiHA

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

Механизм копий баз данных

Платформа «1С:КОРП» (начиная с версии 8.3.14) предложила технологию, название которой вынесено в заголовок. Общая идея заключалась в выносе копии некоторого подмножества таблиц БД 1С в отдельную базу, в которой можно выполнять читающие запросы. Управлять копией может как сама платформа 1С, так и СУБД. Управление со стороны платформы 1С требует дополнительных накладных расходов на поддержание актуальности копии. Если копией управляет СУБД, туда выносятся все таблицы, что, казалось бы, делает реплику БД идеальным кандидатом на автоматически актуализируемую копию. Но тут возникают сложности, для понимания которых требуется немного погрузиться в технологии СУБД в целом и PostgreSQL в частности.

Термины и технологии

PostgreSQL — в статье этим термином обозначим как «ванильный» PostgreSQL, так и любую его ветку, включая патчи от 1С, «Тантор» и Postgres Pro.

Системный каталог (system catalog) — набор таблиц с метаданными экземпляра: список таблиц, индексов, полей и так далее.

Экземпляр (instance) PostgreSQL — служба СУБД, работающая с отдельным каталогом файловой системы. В классической терминологии PostgreSQL этот каталог именуется кластером, но во избежание путаницы в статье мы используем термин «экземпляр».

Журналы предзаписи (write-ahead log, WAL) — файлы, в которые записываются все изменения экземпляра PostgreSQL. Аналоги: в Oracle — redo log, в MS SQL — transaction log.

Репликация — передача журналов предзаписи с экземпляра, где были произведены изменения, на другие экземпляры. Бывает физической (изменения передаются в формате «запиши в файле X в блок Y данные Z») и логической (записи вида «в таблице X добавь/удали/измени строку Y»). Физическая репликация требует полной идентичности каталога СУБД на уровне файловой системы, логическая — только совпадения структуры таблиц.

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

Отказоустойчивый кластер (или просто кластер) — набор экземпляров PostgreSQL, объединённых репликацией и управляемых специализированным кластерным ПО, которое обеспечивает автоматическое переключение узлов при сбое. Экземпляры в составе кластера — это узлы (nodes). Существуют кластерные решения на основе логической репликации, но для 1С они не применяются и в статье не рассматриваются. Физическая репликация всегда однонаправленная: пишущая нагрузка в любой момент выполняется только на одном экземпляре, поэтому такие кластеры часто определяют как Active/Passive — с разделением на активный (пишущий) экземпляр и пассивные (читающие).

Мастер (primary) / лидер (leader) — активный узел кластера.

Реплики (standbys) / последователи (followers) — пассивные узлы. Реплика с параметром hot_standby = on способна принимать читающую клиентскую нагрузку. Отдельно в кластере может присутствовать голосующий узел без пользовательских данных — рефери (referee), нужный для поддержания кворума (минимального числа узлов, необходимого для выбора нового лидера) и гарантии единственности лидера даже при разделении сети.

BiHA (Built-in High Availability) — кластерное ПО от Postgres Professional, встроенное в Postgres Pro Enterprise; позволяет развернуть и контролировать кластер экземпляров Postgres Pro без дополнительных компонентов.

Proxima — расширение Postgres Pro, объединяющее функции прокси, балансировщика нагрузки, пула соединений и кеша данных в оперативной памяти. Для 1С применимы только первые две функции.

Копия БД 1С на реплике

Так что же мешает использовать механизм копии БД на реплике PostgreSQL?

Камнем преткновения становятся временные таблицы, которые 1С в изобилии создаёт в любом более-менее сложном отчёте. Причём проблема даже не в данных этих таблиц, которые не попадают в WAL и в файлы экземпляра БД, а в метаданных. Каждое создание временной таблицы порождает записи в системный каталог экземпляра, в частности в таблицы pg_class и pg_attribute. Поскольку содержание данных таблиц при физической репликации должно быть строго идентично, при попытке создать временную таблицу на реплике мы до недавнего времени неизбежно получали ошибку, что закрывало столь потенциально привлекательную возможность. Нас это очень сильно огорчало, и в новой версии Postgres Pro появился функционал, убирающий столь досадное препятствие. Функционал состоит из двух частей:

Каталог временных таблиц в памяти

Начиная с версий 16.9.1 и 17.5.1 в Postgres Pro Enterprise появился параметр enable_temp_memory_catalog, предусматривающий возможность разместить метаданные о временных таблицах не в системном каталоге, а в памяти экземпляра. Единственным ограничением является отсутствие зависимостей постоянных объектов от временных, что для 1С не является проблемой, поскольку подобных зависимостей она никогда не создаёт. Данный механизм позволил полностью убрать влияние создания и удаления временных таблиц на постоянные объекты, включая WAL и таблицы с метаданными, что дало прирост производительности при активной работе с временными таблицами за счёт уменьшения объёма WAL и предотвращения распухания системного каталога. Само по себе это ещё не позволяло создавать временные таблицы на реплике, но главное препятствие было устранено.

Временные таблицы на реплике

В вышедшей в июне 2026 года версии Postgres Pro Enterprise 18.4.1 реализован полноценный механизм создания временных таблиц на реплике, окончательно убравший препятствия для использования реплики Postgres Pro в качестве автоматически обновляемой копии базы данных 1С. Для его включения на стороне СУБД надо произвести следующие настройки:

• на всех узлах кластера установить enable_temp_memory_catalog = on;
• на реплике установить hot_standby = on (включено по умолчанию) для разрешения чтения с реплики;
• на реплике установить enable_standby_temp_tables = on .

После этого к реплике можно подключаться, создавать и наполнять временные таблицы и выполнять по ним запросы. Есть некоторые ограничения, например нельзя комментировать и переименовывать временные таблицы, но 1С такого не делает, так что со стороны СУБД всё готово для задействования механизма копии БД 1С!

Если на реплике выполняются длительные запросы, рекомендуем установить значение параметра hot_standby_feedback = on, чтобы не допускать отмен запросов, вызванных очисткой записей. При этом надо следить за объёмом WAL на лидере.

BiHA и Proxima

Отказоустойчивый кластер по своей природе должен сохранять рабочее состояние при отказе одного или нескольких узлов. При аварийном или штатном изменении конфигурации кластера адреса лидера и реплики меняются. Хотелось бы избежать необходимости проводить перенастройку ИБ 1С и копии БД. Есть несколько вариантов решения данной проблемы, но мы предлагаем использовать расширение Proxima, начиная с версии 18.4.1 его можно размещать на рефери. Поскольку рефери не содержит пользовательских данных, он потребляет мало ресурсов операционной системы и не нуждается в приобретении лицензий Postgres Pro, что позволяет размещать его прямо на сервере 1С, работающем на Linux. В результате получается вот такая конфигурация

Proxima принимает соединения на двух портах, proxima.port (по умолчанию 4545) и proxima.p2f_port (по умолчанию 4547), первый перенаправляет на действующего лидера, второй — на одного из ведомых. В результате можно указать основное подключение к серверу СУБД как localhost port=4545, а подключение к серверу копии БД — как localhost port=4547, и вне зависимости от текущей конфигурации кластера все подключения будут идти туда, куда необходимо. Аутентификация будет выполняться на лидере, что гарантирует корректную работу при создании БД сервером 1С.

Поскольку 1С содержит свой пул соединений, функционал пулера на Proxima желательно отключить, чтобы не создавать дополнительной нагрузки на СУБД. К сожалению, параметр proxima.force_dedicated нельзя задать на уровне сервера, но его можно настроить на уровне базы данных или пользователя. Мы рекомендуем указывать его именно на уровне пользователя, чтобы при пересоздании БД он не потерялся. Сделать это можно командой

ALTER ROLE pg_1c_owner SET proxima.force_dedicated = true;

где pg_1c_owner — имя пользователя, под которым 1С подключается к СУБД.

В ситуации, когда у вас есть кластер серверов 1С, Proxima необходимо установить на каждом из серверов. Важный момент: чтобы гарантировать корректный кворум, общее число голосующих узлов должно быть нечётным, поэтому в случае одной реплики надо оставить голосующим только один рефери, а если реплик две — отключить голосование на всех, установив параметр biha.can_vote = false.

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

Производительность vs отказоустойчивость

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

Что это даёт

Цель всего этого непростого механизма — повысить производительность высоконагруженной системы 1С. 

Во-первых, отчёты, работающие на копии БД, не нагружают лидера и не влияют на оперативную работу пользователей.

Во-вторых, на реплике можно изменить параметры конфигурации таким образом, чтобы оптимизировать именно длинные отчёты, например увеличив параллелизм.

Краткая инструкция

1. Установить Postgres Pro Enterprise на два узла СУБД и на сервер 1С (без инициализации экземпляра)
2. Проинициализировать кластер BiHA на лидере
3. Установить параметры:
   1. enable_temp_memory_catalog = on;
   2. enable_standby_temp_tables = on;
4. Добавить в кластер BiHA ведомый узел и последователь
5. Создать в базе пользователя 1С

CREATE ROLE pg_1c_owner WITH LOGIN;

ALTER ROLE pg_1c_owner SET proxima.force_dedicated = true;

6. Создать информационную базу на сервере 1С, подключившись по адресу localhost port=4545
7. Настроить конфигурацию, загрузить данные
8. Создать копию БД, подключившись по адресу localhost port=4547
9. Настроить отчёты на использование копии БД