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

Когда Postgres Pro Enterprise загружает разделяемую библиотеку multimaster, код multimaster создаёт поставщика и потребителя логической репликации для каждого узла и внедряется в процедуру фиксирования транзакций. Типичная последовательность действий при репликации данных включает следующие фазы:

Если узел отказывает или отключается от кластера между фазами PREPARE и COMMIT, фаза PRECOMMIT даёт гарантию, что оставшиеся в строю узлы имеют достаточно информации для завершения подготовленной транзакции. Сообщения PRECOMMITTED помогают избежать ситуации, когда отказавший узел зафиксировал или прервал транзакцию, но не успел уведомить о состоянии транзакции другие узлы. При двухфазной фиксации (2PC, two-phase commit), такая транзакция должна блокировать ресурсы (удерживать блокировки) до восстановления отказавшего узла. В противном случае данные могут оказаться несогласованными после восстановления. Это возможно, например, если отказавший узел зафиксирует транзакцию, а оставшийся узел откатит её.

Для фиксирования транзакции служебный процесс должен получить ответ от большинства узлов. Например, в кластере из 2N + 1 узлов необходимо получить минимум N + 1 ответов. Таким образом multimaster обеспечивает доступность кластера для чтения и записи, пока работает большинство узлов, и гарантирует согласованность данных при отказе узла или прерывании соединения.

Так как multimaster допускает запись на всех узлах, он должен ждать ответа с подтверждением транзакции от всех остальных узлов. Если не принять специальных мер, в случае отказа узла для фиксации транзакции пришлось бы ждать пока он не будет восстановлен. Чтобы не допустить этого, multimaster периодически опрашивает узлы и проверяет их состояние и соединение между ними. Когда узел не отвечает на несколько контрольных обращений подряд, этот узел убирается из кластера, чтобы оставшиеся в строю узлы могли производить запись. Частоту обращений и тайм-аут ожидания ответа можно задать в параметрах multimaster.heartbeat_send_timeout и multimaster.heartbeat_recv_timeout, соответственно.

Например, предположим, что кластер с пятью ведущими узлами в результате сетевого сбоя разделился на две изолированных подсети так, что в одной оказалось два, а в другой — три узла кластера. На основе информации о доступности узлов multimaster продолжит принимать запросы на запись на всех узлах в большем разделе и запретит запись в меньшем. Таким образом, кластер, состоящий из 2N + 1 узлов может справиться с отказом N узлов и продолжать функционировать пока будут работать и связаны друг с другом N + 1 узлов. Вы также можете организовать кластер из двух узлов с дополнительным легковесным узлом-рефери (не содержащим данные), который будет устранять неопределённость при симметричном разделении узлов. За подробностями обратитесь к Подразделу F.35.3.3.

В случае частичного разделения сети, когда разные узлы связаны с другими по-разному, multimaster находит подмножество полностью связанных узлов и отключает все узлы вне этого подмножества. Например, в кластере с тремя узлами, если узел A может связаться и с B, и с C, а узел B не может связаться с C, multimaster изолирует узел C, чтобы A и B могли полноценно работать дальше.

Чтобы сохранить порядок транзакций на разных узлах и, как следствие, целостность данных, решение об исключении или возвращении узлов в кластер должно приниматься согласованно. Для принятия таких решений введены поколения — подмножества узлов, считающихся рабочими. На техническом уровне поколением является пара <n, представители>, где n — уникальный номер, а представители — подмножество настроенных узлов кластера. Узел всегда относится к какому-либо поколению и переходит в поколение со следующим номером как только узнаёт о его существовании; номера поколений работают здесь как логические часы/сроки/эпохи. В каждой транзакции при фиксировании отмечается текущее поколение узла, на котором она выполняется. Транзакция может быть предложена для окончательного фиксирования только после того, как она будет подготовлена на всех представителях поколения. Это позволяет разработать протокол восстановления так, чтобы порядок конфликтующих фиксируемых транзакций был на всех узлах одинаковым. Узлы существуют в поколении в одном из трёх состояний (текущее показывает функция mtm.status()):

Работающие узлы не имеют возможности отличить отказавший узел, переставший обрабатывать запросы, от узла в недоступной сети, к которому могут обращаться пользователи БД, но не другие узлы. Если во время фиксирования или записи транзакции некоторые из представителей текущего поколения отключаются, транзакция отменяется в соответствии с правилами поколений. Для предотвращения бесполезных действий соединение проверяется и в начале транзакции; если вы попытаетесь обратиться к изолированному узлу, multimaster выдаст сообщение об ошибке, говорящее о текущем состоянии узла. Во избежание чтения неактуальных данных на нём запрещаются также запросы только на чтение. Таким образом, если вы захотите продолжить использовать отключённый узел вне кластера в независимом режиме, вам нужно будет удалить на этом узле расширение multimaster, как описано в Подразделе F.35.4.5.

Каждый узел поддерживает свою структуру данных, в которой учитывает состояние всех узлов относительно него самого. Вы можете получить эту информацию, воспользовавшись функциями mtm.status() и mtm.nodes().

Когда ранее отказавший узел возвращается в кластер, multimaster начинает автоматическое восстановление:

Корректность протокола восстановления была проверена по модели TLA+. Модель с подробным описанием вы можете найти в doc/specs в каталоге исходного кода multimaster.

Для автоматического восстановления требуется наличие всех файлов WAL, сгенерированных после отказа узла. Если узел был отключён долгое время и сохранить больший объём WAL невозможно, вам придётся исключить этот узел из кластера и вручную восстановить его с одного из работающих узлов, используя pg_basebackup. За подробностями обратитесь к Подразделу F.35.4.3.

Предположим, что вам нужно организовать кластер из трёх узлов с именами node1, node2 и node3. Установив Postgres Pro Enterprise на всех узлах, вы должны проинициализировать каталог данных на каждом узле, как описано в Разделе 18.2. Если вы хотите настроить multimaster для уже существующей базы данных mydb, вы можете загрузить данные из mydb на один из узлов после инициализации кластера либо загрузить данные на все узлы до инициализации, используя любое удобное средство, например, pg_basebackup или pg_dump.

Когда каталог данных будет подготовлен, выполните следующие действия на всех узлах кластера:

SELECT mtm.make_table_local('table_name') 

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

По умолчанию multimaster определяет состояние кворума в подмножестве узлов, учитывая состояние большинства: кластер может продолжать работать, только если функционирует большинство узлов и эти узлы могут связаться друг с другом. Подход с выбором большинства не имеет смысла для кластера с двумя узлами: если один узел отключается, второй тоже перестаёт работать. Однако имеется особый режим с рефери (2+1), который требует меньше аппаратных ресурсов, но и менее отказоустойчив — два узла содержат полностью одинаковые данные, а отдельный узел-рефери нужен только, чтобы отдать голос одному из узлов.

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

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

Во избежание «раздвоения» в кластере должен быть только один рефери.

Чтобы настроить рефери в своём кластере:

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

В случае какого-либо сбоя процедура голосования вызывается снова. При этом все узлы могут оказаться недоступными на короткое время, пока рефери не выберет новое выигрышное подмножество. В этот момент при попытке подключения к кластеру вы можете получить следующее сообщение: [multimaster] node is not online: current status is "disabled" ([multimaster] узел не работает: текущее состояние — «выключен»).

В составе расширения multimaster есть несколько функций, позволяющих наблюдать за текущим состоянием кластера.

Для проверки свойств определённого узла воспользуйтесь функцией mtm.status():

SELECT * FROM mtm.status();

Для получения списка всех узлов в кластере и их состояния вызовите функцию mtm.nodes():

SELECT * FROM mtm.nodes();

Выдаваемая ими информация подробно описана в Подразделе F.35.5.2.

Если узел кластера отключён, при любой попытке записать или прочитать данные на этом узле по умолчанию выдаётся ошибка. Если вы хотите обращаться к данным на отключённом узле, это поведение можно переопределить при подключении, передав параметр application_name со значением mtm_admin. Таким образом, вы сможете выполнять на этом узле запросы на чтение и запись без контроля multimaster.

Используя multimaster, вы можете добавлять или удалять узлы кластера. Прежде чем добавить узел, снимите нагрузку и убедитесь (воспользовавшись функцией mtm.status()) в том, что все узлы, которые должны быть в кластере, находятся в рабочем состоянии (online). Чтобы добавить новый узел, на него нужно загрузить все данные, выполнив pg_basebackup на любом узле кластера, а затем запустить его.

Предположим, что у нас есть работающий кластер с тремя узлами с именами node1, node2 и node3. Чтобы добавить node4, следуйте этим указаниям:

Перед удалением узлов снимите нагрузку и убедитесь (воспользовавшись функцией mtm.status()), что все узлы, за исключением удаляемых, находятся в рабочем состоянии (online). Отключите узлы, которые вы намерены удалить. Удалите узлы из кластера:

Если вы позже захотите возвратить узел в кластер, вам придётся добавить его как новый узел. За подробностями обратитесь к Подразделу F.35.4.3.

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

Выполнив все эти действия, вы можете использовать этот узел в независимом режиме, если это требуется.

Вы можете убедиться в том, что данные на всех узлах кластера одинаковые, воспользовавшись функцией mtm.check_query(query_text).

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

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

postgres=# SELECT mtm.check_query('SELECT * FROM my_table ORDER BY id');
 check_query
-------------
 t
(1 row)

postgres=# SELECT mtm.check_query('SELECT * FROM my_table');
WARNING: mismatch in column 'b' of row 0: 256 on node0, 255 on node1
 check_query
-------------
 f
(1 row)

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

Когда отстающий узел навёрстывает состояние узла-донора и не может быстро применять изменения, можно замедлить выполнение транзакций на узле-доноре с помощью параметра конфигурации multimaster.tx_delay_on_slow_catchup . Для этого задайте этому параметру значение on в файле конфигурации postgresql.conf на узле-доноре, но не на отстающем узле-партнёре. Если вы редактируете файл на работающем сервере, нужно передать сигнал postmaster перечитать файл (за подробностями обратитесь к Главе 19). При необходимости также можно указать максимально возможную задержку выполнения транзакций в необязательном параметре multimaster.max_tx_delay_on_slow_catchup (в миллисекундах). При значении 0 максимальная задержка отключена. В настоящее время задержка может варьироваться от 1 мс до приблизительно 4 секунд. Значения за пределами допустимого диапазона будут усечены до ближайшего допустимого значения.

По умолчанию эта функциональность отключена.

По умолчанию все операторы DDL выполняются на всех узлах кластера, за исключением следующих, которые могут воздействовать только на локальный узел:

Механизм репликации основан на логическом декодировании и предыдущей версии расширения pglogical, которым поделилась с сообществом команда 2ndQuadrant.

Алгоритм консенсуса Паксос описан в статье:

Механизм параллельной репликации и восстановления реализован по принципам, изложенным в работе: