Стабильная работа кластера YMatrix обеспечивается тремя ключевыми модулями процессов. Каждый из них выполняет собственные задачи, одновременно взаимодействуя с другими для формирования полноценной распределённой архитектуры обработки данных.
Известен как «генеральный менеджер» процессов кластера. Это системная служба, запускаемая при установке кластера и работающая с привилегиями root. Её основные функции:
Supervisor является фундаментом для старта и мониторинга всех процессов кластера.
Выступают в роли «диспетчерского центра» кластера. Основаны на процессах серии mxbox и интегрируют все необходимые для распределённого управления сервисные возможности:
cluster) shard) replication) deployer) Эти процессы используют etcd для хранения метаданных кластера и обеспечения согласованности между узлами.
Являются «вычислительным ядром» кластера и работают на узлах Master, Standby и Segment. Их задачи:
/etc/matrixdb6/supervisor.conf | Модуль | Основная функция |
|---|---|
mxbox cluster |
Управление топологией кластера, добавление/удаление узлов, синхронизация состояний |
mxbox shard |
Распределение и планирование шардов, балансировка нагрузки, привязка шардов к Segment-узлам |
mxbox replication |
Управление политиками репликации, синхронизация и переключение между Master–Standby и Primary–Mirror |
mxbox deployer |
Автоматизированное развёртывание: инициализация узлов, установка ПО, синхронизация конфигураций и другие O&M-операции |
supervisord и etcd, обеспечивая гибкость и эффективность эксплуатации.| Тип узла | Роль процесса (gp_role) |
Пример запуска | Основная функция |
|---|---|---|---|
| Master | Dispatch (диспетчер) | -p 5432 -D /mxdata/master/mxseg-1 |
Принимает подключения клиентов, строит распределённые планы запросов, координирует выполнение QE, агрегирует результаты |
| Standby | Dispatch (резервный диспетчер) | -p 5432 -D /mxdata/standby/mxseg-1 |
Синхронизирует данные с Master, обеспечивает отказоустойчивость, принимает роль Master при его сбое |
| Segment (Primary) | Execute (исполнитель) | -p 6000 -D /mxdata/primary/mxseg0 |
Хранит данные, выполняет Slice-задачи от QD, отправляет WAL-логи Mirror |
| Segment (Mirror) | Execute (резервный исполнитель) | -p 7001 -D /mxdata/mirror/mxseg6 |
Синхронизирует данные с Primary, обеспечивает резервирование, заменяет Primary при сбое |
postgres-процесса порождаются вспомогательные процессы — для логирования, оптимизации хранилища, обеспечения транзакций и т.д., совместно реализуя полный цикл обработки данных.Роль: «Исполнитель на передовой» запросов.
Функции:
Особенности:
Роль: «Хранитель» от взаимоблокировок в распределённых транзакциях.
Функции:
Значение: В распределённой СУБД, где транзакции часто затрагивают несколько узлов, этот процесс критически важен для поддержания стабильности при высокой параллельности.
| Процесс | Размещение | Функция |
|---|---|---|
| walwriter | Master / Primary | Записывает WAL-логи из памяти на диск, обеспечивая локальную персистентность |
| walsender | Master / Primary | Передаёт WAL-логи в реальном времени на Standby / Mirror |
| walreceiver | Standby / Mirror | Принимает WAL-логи от walsender и записывает их локально |
Процессы кластера YMatrix имеют иерархическую древовидную структуру с корнем в supervisord. Ниже представлена организация ключевых процессов по функциональным группам.
supervisord (корневой процесс)
├─ Уровень SOA-сервисов
│ ├─ mxbox cluster (управление топологией кластера)
│ ├─ mxbox shard (управление распределением шардов)
│ ├─ mxbox replication (репликация данных и отказоустойчивость)
│ ├─ mxbox deployer (автоматизированное развёртывание)
│ └─ etcd (хранилище метаданных кластера)
├─ Уровень системного управления и мониторинга
│ ├─ mxui (веб-интерфейс управления)
│ ├─ cylinder (периодические задачи обслуживания)
│ └─ telegraf (сбор и экспорт метрик мониторинга)
└─ Уровень экземпляров базы данных (разветвляется по типам узлов)
├─ MASTER-узлы
│ ├─ postgres (основной процесс, gp_role=dispatch)
│ │ ├─ Процессы логирования и базовой инфраструктуры (master logger, mxlogstat и др.)
│ │ ├─ Процессы оптимизации хранилища (checkpointer, walwriter и др.)
│ │ ├─ Процессы распределённых функций (dtx recovery, глобальный детектор взаимоблокировок и др.)
│ │ └─ Процесс планирования запросов (QD: Query Dispatcher)
│ └─ matrixgate warden (управление подключениями через шлюз)
├─ STANDBY-узлы
│ └─ postgres (резервный процесс, gp_role=dispatch)
│ ├─ Базовые процессы обеспечения (logger, checkpointer и др.)
│ └─ Процессы синхронизации данных (walreceiver, startup recovering)
└─ SEGMENT-узлы (Primary / Mirror)
├─ postgres (процесс экземпляра, gp_role=execute)
│ ├─ Базовые процессы обеспечения (logger, mxlogstat и др.)
│ └─ Процесс выполнения запросов (QE: Query Executor)
├─ Уникальные процессы Primary (walsender: отправка WAL-логов)
└─ Уникальные процессы Mirror (walreceiver: приём WAL-логов, startup recovering: восстановление данных)Клиенты подключаются к узлу Master через протокол libpq. QD (Query Dispatcher) устанавливает соединения со всеми соответствующими QE (Query Executor) на Segment-узлах, формируя сквозную сессионную цепочку для совместного выполнения распределённых запросов.
Клиентская сессия
├─ Узел Master: postmaster (ожидает подключений) → создаёт дочерний процесс QD (планировщик, привязанный к сессии)
│ └─ QD подключается к postmaster каждого Segment-узла через протокол libpq
└─ Segment-узлы: postmaster → создаёт дочерний процесс QE (исполнитель, привязанный к сессии)
├─ Двунаправленная связь QD ↔ QE:
│ - Управление и статус: протокол libpq
│ - Обмен данными: протокол interconnect
└─ Жизненный цикл сессии:
- QD управляет разбором запроса, распределением плана и агрегацией результатов
- QE выполняет конкретные операции обработки данныхОсновная функция: сложные запросы разбиваются на несколько независимых параллельных задач (Slice’ов), каждая из которых выполняется отдельным QE на разных узлах, что значительно повышает эффективность обработки.
План запроса
└─ Разделяется на несколько Slice’ов (независимых вычислительных единиц) на основе операций Motion (перемещение данных)
├─ Каждый Slice представляет собой отдельную задачу обработки (фильтрация, агрегация, соединение и т.д.)
├─ Физический носитель: один QE-процесс выполняет один Slice
└─ Иерархия: Producer Slice (выдаёт данные) → операция Motion → Consumer Slice (потребляет данные)Задача Slice
└─ Gang (группа процессов)
├─ Состав: все QE-процессы на разных Segment-узлах, выполняющие один и тот же Slice
├─ Особенность: QE внутри одного Gang’а работают синхронно, выполняя идентичную логику Slice
└─ Назначение: обеспечивает согласованность параллельного выполнения одной и той же части запроса в распределённой среде,
позволяя эффективно координировать обработку данных между узлами