Postgres Pro Enterprise 13
Синхронный кластер multimaster
13
Авторские права
© Postgres Professional, 2023 год.
Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Возможности и ограничения
Архитектура и принцип работы
Распределенные транзакции
Поколения узлов
Проверка состояния узлов
Отказ узла
Режим 2+1
3
Возможности
Синхронный симметричный кластер
на всех узлах одинаковые данные, все узлы ведущие
Распределенные транзакции
все узлы работают как единая СУБД с ACID-гарантиями
Отказоустойчивость и высокая доступность
Масштабируемость чтения
Расширение multimaster позволяет преобразовать сервер в синхронный
симметричный кластер без разделения ресурсов — данные будут
одинаковы на всех узлах кластера, клиенты могут читать и писать
данные на любой из узлов. В кластере поддерживаются
распределенные транзакции, дающие обычные гарантии ACID, поэтому
приложения могут работать с кластером как с единой СУБД.
Multimaster обеспечивает отказоустойчивость за счет автоматического
восстановления данных на вернувшихся в строй узлах; кластер имеет
высокую доступность — у него нулевое время простоя. Менять
конфигурацию (в том числе и обновлять в рамках одной и той же
основной версии) узлов можно без остановки обслуживания.
Перенаправляя на разные узлы читающие транзакции, можно повысить
пропускную способность таких операций.
4
Ограничения
Не поддерживаются
ОС Windows и решения 1С
репликация нескольких баз данных
большие объекты (Large Objects)
операции неблокирующего построения и перестроения индексов
и работы с табличными пространствами
Особенности работы с данными
транзакции могут занимать длительное время
на уровне Read Committed могут происходить сбои сериализации
меняется поведение последовательностей
OID могут отличаться на разных узлах
Некоторые другие особенности и ограничения
У расширения есть ряд ограничений.
Не поддерживается ОС Windows и продукты 1С.
Можно реплицировать только одну базу данных (но можно сделать
несколько кластеров для разных баз данных).
Не поддерживаются большие объекты (Large Objects).
Не поддерживаются операции CREATE INDEX и REINDEX
с предложением CONCURRENTLY, CREATE и DROP TABLESPACE.
Так как каждая транзакция подтверждается несколькими узлами, это
занимает некоторое время. Чем больше узлов в кластере, тем дольше
будет происходить фиксация изменений.
На уровне изоляции Read Committed транзакции могут завершаться
ошибкой сериализации.
Последовательности по умолчанию выдают немонотонные значения,
чтобы избежать конфликтов уникальных идентификаторов между
узлами.
Идентификаторы OID могут быть различными на разных узлах.
Существуют и некоторые другие ограничения использования
мультимастера.
6
Архитектура
r/w
Postgres Pro
(расширение
+ набор патчей
ядра)
r/w
r/w
логическая
репликация,
E3PC
Расширение multimaster состоит из патчей ядра СУБД (входят
в Postgres Pro) и непосредственно кода расширения.
Данные передаются между узлами с помощью доработанного
механизма логической репликации.
Для обеспечения согласованности данных подтверждение
распределенных транзакций выполняется с помощью улучшенного
трехфазного протокола фиксации (E3PC). Для этого в кластере
изначально должно быть не менее трех узлов.
Высокая степень доступности достигается тем, что узлы можно
выводить из кластера и добавлять к кластеру «на лету». При этом
клиенты могут быть подключены к любому узлу — все узлы принимают
и читающую, и пишущую нагрузку.
7
Процессы
mtm-monitor
mtm-dmq-sender mtm-dmq-receiver
walsender mtm-logrep-receiver
mtm-logrep-receiver-dynworker
mtm-resolver
mtm-campaigner
mtm-replier
служебная информация:
фиксация транзакций
и опрос доступности
логическая репликация
отработка потерь узлов
и восстановлений
За разные задачи в мультимастере отвечают разные процессы:
●
Процесс mtm-monitor запускается на каждом узле и управляет
остальными процессами кластера.
●
Процесс mtm-logrep-receiver получает поток логической репликации
от walsender. Изменения применяются пулом процессов mtm-logrep-
receiver-dynworker.
●
Процесс mtm-dmq-sender посылает mtm-dmq-receiver служебную
информацию, необходимую для реализации распределенных
транзакций, а также выполняет периодический опрос доступности
узлов (DMQ — distributed message queue, распределенная очередь
сообщений).
●
Процессы mtm-resolver и mtm-campaigner служат для согласованного
исключения узлов из кластера и возвращения узлов в кластер; им
отвечает процесс mtm-replier.
На рисунке показаны только процессы-источники одного узла и
соответствующие им процессы-приемники другого узла. На самом деле
и те процессы, и другие работают на каждом узле. Более того, их
количество зависит от числа узлов в кластере: например, на каждом
узле будет запущен процесс walsender для каждого из остальных узлов
кластера.
9
Фиксация изменений
c
o
m
m
i
t
p
r
e
p
a
r
e
p
r
e
p
a
r
e
d
(
в
с
е
у
з
л
ы
)
p
r
e
c
o
m
m
i
t
p
r
e
c
o
m
m
it
t
e
d
(
б
о
л
ь
ш
и
н
с
т
в
о
)
c
o
m
m
i
t
c
o
m
m
i
t
t
e
d
координатор другие узлы
Протокол трехфазной фиксации расширяет стандартный протокол
двухфазной фиксации, реализованный в PostgreSQL, и работает
следующим образом:
1. Prepare. Когда на узле (который считается координатором
транзакции) выполняется оператор COMMIT, транзакция
подготавливается (PREPARE TRANSACTION) и передается на
остальные доступные узлы. Эти узлы отвечают подтверждением или
отказом.
Если какой-либо узел ответил отказом, транзакция обрывается.
2. Precommit. Узел-координатор рассылает остальным узлам команду
Precommit, которая выражает намерение зафиксировать транзакцию.
Для продолжения достаточно, чтобы подтверждением ответило
большинство узлов (кворум). Если достаточного количества
подтверждений не набирается, транзакция обрывается (ROLLBACK
PREPARED).
3. Commit. Транзакция фиксируется на всех узлах (COMMIT
PREPARED).
В отличии от двухфазной фиксации, в трехфазную добавлен этап
Precommit. Если после него произойдет сбой одного из узлов и третий
этап Commit не будет выполнен на сбойном узле, на остальных узлах
заключительный этап завершится по тайм-ауту и транзакция успешно
зафиксируется.
%3Dihub
10
Поколения узлов
1
3
2
Поколение 1: {1,2,3}
Большинство узлов (но и не только оно) определяется с помощью
поколений. Поколение — это подмножество узлов, считающихся
в данный момент рабочими.
Поколение определяется номером (монотонно возрастающее значение)
и перечнем представителей этого поколения. Узел всегда входит
в какое-либо поколение. Если узел видит, что существует поколение
с бо
~
льшим номером, он старается перейти в него.
Новое поколение формируется большинством доступных узлов
кластера на момент его запуска, после сбоя узлов и при добавлении
в кластер нового узла.
Транзакцию можно зафиксировать только после того, как она будет
подготовлена на всех представителях поколения.
На слайде проиллюстрирована ситуация кластера из трех узлов
(поколение 1).
12
Отказ узла
Поколение 1: {1,2,3}
Поколение 2: {1,2}
1
3
2
При отказе одного из узлов (выключение узла, недоступность узла по
сети) оставшиеся узлы формируют новое поколение и в дальнейшем
транзакции подтверждаются большинством из оставшихся узлов.
14
Восстановление узла
1
3
2
Поколение 1: {1,2,3}
Поколение 2: {1,2}
Поколение 3: {1,2,3}
После восстановления третьего узла он определяет номер текущего
поколения кластера, получает список узлов, находящихся в этом
поколении и выполняет восстановление с одного из этих узлов.
После окончания восстановления третий узел предлагает включить его
в кластер, формируя новое поколение 3.
16
Режим 2+1
рефери
Для работы синхронного симметричного кластера требуется, чтобы все
узлы кластера были примерно одинаковы по их аппаратным
характеристикам.
Помимо этого, существует режим работы кластера мультимастера 2+1
(его еще называют режимом работы с рефери). В этом случае
в кластер входят два полноценных узла, а третий узел работает только
как голосующий — он принимает решения о подтверждении и отмене
транзакций.
На узле-рефери достаточно установить Postgres Pro Enterprise и
добавить расширение referee. Узел-рефери не хранит никакие данные
кластера, поэтому он создает небольшую нагрузку и не требователен
к ресурсам.
18
Итоги
Postgres Pro Multimaster — это кластерное решение
со всеми ведущими узлами, обеспечивающее
автоматическое восстановление узлов после сбоев
Не требует установки дополнительного ПО
Сфера применения — системы высокой доступности
19
Практика
1. Настройте кластер для режима работы 2+1.
2. Имитируйте отказ одного из двух узлов и проверьте
работоспособность кластера.
3. Верните отключенный узел в строй.
1. Подготовьте три дополнительных экземпляра Postgres Pro Enterprise:
для каждого из них инициализируйте каталог данных, настройте
аутентификацию и задайте параметры. Подробности можно посмотреть
в решении практики.
