Обзор архитектуры ADPG

Arenadata Postgres (ADPG) — СУБД для эффективной работы с данными, имеющими разный профиль нагрузки (преимущественно OLTP — Online Transaction Processing). ADPG позволяет работать с различными объемами данных и поддерживает широкий спектр типов данных, включая JSON и пользовательские типы, а также предоставляет инструментарий для создания механизмов обработки данных.

Архитектура ADPG
Архитектура ADPG
Архитектура ADPG
Архитектура ADPG

Основные компоненты кластера на схеме:

  • BackupAgent — создание резервных копий и загрузка их в хранилище. В основе BackupAgent лежит утилита по управлению резервным копированием pgBackRest.

  • BackupManager — управление созданием и хранением резервных копий.

  • ADPG leader — основной хост, имеющий право выполнять write-транзакции.

  • ADPG replica — дополнительные хосты, являющиеся репликами leader-хоста.

  • etcd — распределенное хранилище конфигураций.

  • Proxies — распределение read/write транзакций между лидером и репликами (HAProxy).

  • Connection Poolers — экземпляры PgBouncer, установленные на каждой ноде ADPG, которые управляют количеством соединений и их переиспользованием.

ADPG использует Patroni для создания кластера на основе потоковой репликации PostgreSQL и реализации отказоустойчивости (High Availability,HA). Кластер ADPG, поддерживающий HA, должен содержать несколько нод ADPG. Каждая нода содержит сервер PostgreSQL и агент Patroni, обслуживающий локальный экземпляр PostgreSQL. Одна нода ADPG является лидером, остальные — репликами. Лидер обслуживает транзакции на чтение и запись (read-write), если иное не указано в настройках сервиса балансировки, а реплики — только запросы на чтение (read-only). В случае отказа лидера Patroni выбирает нового лидера из реплик, и кластер ADPG продолжает работу.

Patroni сохраняет конфигурацию кластера в распределенном хранилище конфигурации (Distributed Configuration Storage, DCS). ADPG требует наличия кластера etcd, чтобы использовать его в качестве DCS для Patroni.

Для того чтобы реализовать балансировку нагрузки, в ADPG используется HAProxy (High Availability Proxy). HAProxy является программным балансировщиком нагрузки TCP/HTTP. HAProxy слушает порты попарно: подключения к одному из них передаются лидеру, запросы ко второму распределяются по ADPG-нодам. За дополнительной информацией обратитесь к статье Балансировка нагрузки.

PgBouncer управляет пулом соединений ADPG. Приложение может подключаться к PgBouncer как к серверу ADPG. PgBouncer создает соединение с сервером ADPG или повторно использует одно из существующих подключений. PgBouncer предназначен для снижения издержек, связанных с установкой новых соединений. Чтобы не нарушать семантику транзакций, PgBouncer поддерживает несколько типов пула при ротации соединений:

  • Пул сессий — при подключении клиента ему присваивается соединение с сервером на все время подключения клиента. Когда клиент отключается, соединение с сервером возвращается в пул. Это метод по умолчанию.

  • Пул транзакций — соединение с сервером назначается клиенту только во время транзакции. Когда PgBouncer замечает, что транзакция завершена, соединение с сервером возвращается в пул.

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

Также частью ADPG является хост для хранения резервных копий — Storage. Вы можете использовать любой тип хранилища, который поддерживается утилитой pgBackRest.

Управление кластером ADPG выполняется через ADCM. Следующие действия доступны в пользовательском интерфейсе ADCM:

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней