Отказоустойчивый кластер СУБД на основе Postgres Pro Enterprise Multimaster

Сокращения

БД – база данных

СУБД – система управления базами данных

ОУК – отказоустойчивый кластер СУБД Postgres Pro

ВМ – виртуальная машина

WAL (англ. Write-Ahead Log) – журнал упреждающей записи

SLA (англ. Service Level Agreement) – соглашение об уровне сервиса

RPO (англ. Recovery Point Objective) – целевая точка восстановления

RTO (англ. Recovery Time Objective) – целевое время восстановления

DNS (англ. Domain Name System) – система доменных имен

Терминология и определения

Multimaster — расширение Postgres Pro Enterprise Edition, которое в сочетании с набором доработок ядра превращает СУБД в синхронный кластер со всеми ведущими узлами, обеспечивающий автоматическое восстановление узлов после сбоев.

Отказоустойчивый кластер – группа экземпляров Postgres Pro, объединенных в логическую группу и образующих единый ресурс.

Улучшенный трехфазный протокол фиксации (E3PC) – улучшает алгоритм трехфазной фиксации (3PC), разрешая фиксировать транзакцию при получении большинства (а не всех) голосов.

Потоковая репликация – репликация, при которой от ведущего сервера Postgres Pro на ведомые передается WAL. Каждый ведомый узел по журналу применяет изменения с ведущего узла.

Логическая репликация — механизм репликации, который формирует поток логических изменений данных, обрабатывая WAL. Логическая репликация позволяет переносить изменения данных на уровне таблиц в платформонезависимом виде; двоичная совместимость не требуется. Для логической репликации не требуется, чтобы за определённым сервером закреплялась роль master или standby; напротив, данные могут передаваться в разных направлениях.

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

В Postgres Pro логическое декодирование реализуется путём перевода содержимого WAL, описывающего изменения на уровне хранения, в специальную форму уровня приложения, например, в поток кортежей или операторов SQL.

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

Узел кластера – физический сервер или виртуальная машина с установленным сервером СУБД Postgres Pro и кластерным программным обеспечением.

Split-brain – появление в кластере одновременно двух узлов, выполняющих роль ведущего узла СУБД

RPO – допустимый объем потерянных данных, измеряется интервалом времени. Любая информационная система должна обеспечивать защиту своих данных от потери не хуже требуемого уровня.

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

DNS – интернет-сервис, распределенная база данных иерархической системы имен узлов сети Интернет (маршрутизаторов, серверов, пользовательских устройств и т.п.), а также способ (протокол прикладного уровня) преобразования символьных адресов (доменных имен) узлов сети Интернет в числовые IP-адреса и обратно.

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

Достоинства Multimaster

Встроенное в СУБД Postgres Pro Enterprise Edition решение отказоустойчивости, максимальная совместимость с Postgres Pro
Не требуется дополнительных лицензий
Не требуется стороннее кластерное ПО

По сравнению с классической конструкцией ведущий-ведомый стандартного кластера PostgreSQL, в кластере Multimaster все узлы являются ведущими. Это даёт следующие преимущества:
- Запись во все узлы или в один (транзакции реплицируются на все узлы)
- Добавление/удаление узла в кластер «на лету»

Устойчивость к сбоям и автоматическое восстановление узлов после сбоя. Например, при продолжительном сетевом сбое с ведущим узлом в стандартном кластере классической конструкции ведущий-ведомый, его роль перейдет к ведомому узлу. После устранения сетевого сбоя, для возврата бывшего ведущего узла в кластер может потребоваться вовлечение администратора в процедуру восстановления. В кластере Multimaster все узлы являются ведущими, при восстановлении сети после сбоя, отказавший узел будет восстановлен автоматически, получая и применяя инструкции из недостающих журналов WAL с других узлов кластера или из архива WAL.
Синхронная логическая репликация и репликация DDL
Масштабируемость чтения

Поддержка работы с временными таблицами на каждом узле кластера

Незаметное для клиентов кластера Multimaster обновление Postgres Pro Enterprise в пределах основной (мажорной) версии. Эта возможность предоставляется благодаря логической репликации путем поочередного:

удаления узла из кластера
обновления удаленного узла в пределах текущей основной версии
добавления обновленного узла обратно в кластер.

Возможности Multimaster

Устойчивость к любому разделению кластера (split-brain). При сетевой изоляции узел переходит в изолированный режим и не принимает подключений
Поддержка работы с временными таблицами на каждом узле кластера

Особенности Multimaster

Поддержка одной БД в кластере Multimaster

Возможное снижение производительности при пишущей нагрузке (ввиду 3-х фазной фиксации изменений)

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

SLA, RTO и RPO

Прежде всего важно определить, требуют ли сервисы архитектуры высокой доступности. Если да, то в какой степени должна быть обеспечена высокая доступность. Доступность сервисов обычно определяется метрикой SLA. В SLA ключевыми метриками являются RPO и RTO. Требования должны подбираться в соответствии с потребностями бизнеса. Например, в некоторых случаях не требуется высокая доступность.

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

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

Формула расчета SLA: ([количество ms в сутках] - [количество ms недоступности кластера в сутках])/([количество ms в сутках])

Доступность сервиса	Продолжительность простоев в неделю	Продолжительность простоев в месяц	Продолжительность простоев в год
99%	1.68 ч	7.2 ч	3,65 дня
99.90%	10.1 мин	43.2 мин	8.76 ч
99.95%	5 мин	21.6 мин	4.38 ч
99.99%	1.01 мин	4.32 мин	52.56 мин
99.999%	6 с	25.9 с	5.26 мин

Таблица 1. Уровни доступности.

Кластеризация базы данных

Основная цель кластеризации базы данных – обеспечить высокую доступность к данным.

Доступность характеризуется свойствами:

Надежность – восстановление без потери данных после сбоя узла кластера СУБД.
Отказоустойчивость – бесперебойная запись и чтение данных в случае сбоя узла кластера СУБД.
Производительность и горизонтальная масштабируемость (по чтению) – возможность добавления новых узлов в кластер СУБД и распределение нагрузки одного узла на остальные узлы кластера СУБД.

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

Для обеспечения высокой степени доступности и отказоустойчивости кластера multimaster определяет результат каждой транзакции по алгоритму консенсуса Paxos, используя специальный протокол восстановления и контроль состояния для обнаружения сбоев. Кластер с N ведущими узлами может продолжать работать, пока функционируют и доступны друг для друга большинство узлов. Чтобы в кластере можно было настроить multimaster, он должен включать в себя как минимум три узла. Так как на всех узлах кластера будут одни и те же данные, обычно нет смысла делать в кластере более пяти узлов. Также поддерживается особая схема 2+1 (с рефери), в которой 2 узла содержат данные, а дополнительный узел, так называемый рефери, только участвует в голосовании. Эта схема, по сравнению с обычной схемой с тремя узлами, обходится дешевле (рефери не предъявляет больших требований к ресурсам), но её степень доступности ниже. Клиенты могут быть подключены к любому узлу — все узлы кластера принимают как читающую, так и пишущую нагрузку (см. Схему 1).

Схема 1. Кластер multimaster, каждый узел которого принимает и читающую, и пишущую нагрузку.

Схема 1. Кластер multimaster, каждый узел которого принимает и читающую, и пишущую нагрузку.

Типовые конфигурации кластера Multimaster

Существует два базовых варианта развертывания отказоустойчивых кластеров multimaster – трехузловые кластеры и двухузловые плюс рефери, т.н. 2+1.

Для работы синхронного симметричного кластера требуется, чтобы все узлы кластера были одинаковы по их аппаратным характеристикам. За исключением режима работы кластера Multimaster 2+1 (его еще называют режимом работы с рефери). В этом случае в кластер входят два полноценных узла, а третий узел работает только как голосующий (см. Схему 2).

Схема 2. Кластер Multimaster 2+1

Схема 2. Кластер Multimaster 2+1

На узле-рефери достаточно установить Postgres Pro Enterprise и добавить расширение referee. Узел-рефери не хранит никакие данные кластера, поэтому он создает небольшую нагрузку и не требователен к ресурсам. Узел-рефери подлежит лицензированию Postgres Pro EE.

Единая точка входа в Multimaster

В качестве единой точки входа в кластер рекомендуется использовать возможность перечислить все узлы кластера Multimaster в строке подключения. Данная возможность реализована в libpq, jdbc, pgx и других драйверах для соединения с СУБД. Если же используются устаревшие версии драйверов, или в драйвере не реализована такая возможность, то можно использовать стороннее ПО, например, tcp-прокси или балансировщик трафика, который может перенаправлять трафик в исправный узел кластера.