F.30. multimaster

multimaster — это расширение Postgres Pro Enterprise, которое в сочетании с набором доработок ядра превращает Postgres Pro Enterprise в синхронный кластер без разделения ресурсов, который обеспечивает масштабируемость OLTP для читающих транзакций, а также высокую степень доступности с автоматическим восстановлением после сбоев.

По сравнению со стандартным кластером PostgreSQL конструкции ведущий-ведомый, в кластере, построенном с использованием multimaster, все узлы являются ведущими. Это даёт следующие преимущества:

  • Устойчивость к сбоям и автоматическое восстановление узлов

  • Синхронная логическая репликация и репликация DDL

  • Масштабируемость чтения

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

  • Обновление серверов Postgres Pro Enterprise «на ходу»

Важно

Прежде чем разворачивать multimaster в производственной среде, примите к сведению ограничения, связанные с репликацией. За подробностями обратитесь к Подразделу F.30.1.

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

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

Когда узел снова подключается к кластеру, multimaster может автоматически привести его в актуальное состояние и наверстать упущенное, используя данные WAL из соответствующего слота репликации. Если узел был полностью исключён из кластера, его можно добавить, используя pg_basebackup.

Чтобы узнать больше о внутреннем устройстве multimaster, обратитесь к Подразделу F.30.2.

F.30.1. Ограничения

Расширение multimaster осуществляет репликацию данных полностью автоматическим образом. Вы можете одновременно выполнять пишущие транзакции и работать с временными таблицами на любом узле кластера. Однако, при этом нужно учитывать следующие ограничения репликации:

  • Операционная система Microsoft Windows не поддерживается.

  • Решения по ряду причин не поддерживаются.

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

  • Большие объекты не поддерживаются. Хотя их можно создать, multimaster не сможет реплицировать такие объекты и их идентификаторы (OID) на разных узлах могут конфликтовать, поэтому использовать большие объекты не рекомендуется.

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

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

  • В отличие от ванильного PostgreSQL, в кластере multimaster на уровне изоляции read committed могут происходить сбои сериализации (с кодом SQLSTATE 40001), если на разных узлах будут выполняться конфликтующие транзакции. Поэтому приложение должно быть готово повторять транзакции в случае сбоя. Уровень изоляции Serializable работает только применительно к локальным транзакциям на текущем узле.

  • Генерация последовательностей. Во избежание конфликтов уникальных идентификаторов на разных узлах, multimaster меняет стандартное поведение генераторов последовательностей. По умолчанию для каждого узла идентификаторы генерируются, начиная с номера узла, и увеличиваются на число узлов. Например, в кластере с тремя узлами идентификаторы 1, 4 и 7 выделяются для объектов, создаваемых на первом узле, а 2, 5 и 8 резервируются для второго узла. Если число узлов в кластере изменяется, величина прироста идентификаторов корректируется соответственно. Таким образом, значения последовательностей будут не монотонными. Если важно, чтобы последовательность во всём кластере увеличивалась монотонно, задайте для параметра multimaster.monotonic_sequences значение true.

  • Задержка фиксации. В текущей реализации логической репликации multimaster передаёт данные узлам-подписчикам только после локальной фиксации, так что приходится ожидать двойной обработки транзакции: сначала на локальном узле, а затем на всех других узлах одновременно. Если транзакция производит запись в большом объёме, задержка может быть весьма ощутимой.

  • При логической репликации не гарантируется, что идентификатор (OID) системного объекта будет одинаковым на всех узлах кластера, поэтому один и тот же объект на разных узлах кластера multimaster может иметь разные OID. Если ваше приложение или драйвер доступа к БД в своей работе полагается на OID, во избежание ошибок обеспечьте для него привязку к одному узлу, без возможности переключения на другие. Например, драйвер Npgsql может работать некорректно с кластером multimaster, если метод NpgsqlConnection.GlobalTypeMapper будет использовать сохранённые внутри драйвера значения OID, подключаясь к разным узлам кластера.

  • Реплицируемые неконфликтующие транзакции применяются на получающих узлах параллельно, так что их результаты могут появляться на разных узлах в разном порядке.

  • Операции CREATE INDEX CONCURRENTLY и REINDEX CONCURRENTLY не поддерживаются.

  • Конструкция COMMIT AND CHAIN не поддерживается.

F.30.2. Архитектура

F.30.2.1. Репликация

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

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

  1. Фаза PREPARE. Код multimaster перехватывает каждый оператор COMMIT и преобразует его в оператор PREPARE. Все узлы, получающие транзакцию через протокол репликации (узлы когорты), передают свой голос для одобрения или отклонения транзакции служебному процессу на исходном узле. Это гарантирует, что вся когорта может принять эту транзакцию и конфликт при записи отсутствует. Подробнее поддержка транзакций с PREPARE в PostgreSQL рассматривается в описании PREPARE TRANSACTION.

  2. Фаза PRECOMMIT. Если все узлы когорты одобряют транзакцию, служебный процесс отправляет всем этим узлам сообщение PRECOMMIT, выражающее намерение зафиксировать эту транзакцию. Узлы когорты отвечают этому процессу сообщением PRECOMMITTED. В случае сбоя все узлы могут использовать эту информацию для завершения транзакции по правилам кворума.

  3. Фаза COMMIT. Если результат PRECOMMIT положительный, транзакция фиксируется на всех узлах.

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

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

F.30.2.2. Обнаружение сбоя и восстановление

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

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

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

Для кластеров с чётным числом узлов вы можете настроить легковесный узел-рефери (не содержащий данных), который будет устранять неопределённость при симметричном разделении узлов. За подробностями обратитесь к Подразделу F.30.3.3.

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

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

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

  1. Вновь подключённый узел выбирает случайный узел кластера и начинает навёрстывать текущее состояние кластера, используя WAL. Чтобы процесс восстановления завершился успешно, на это время пишущие транзакции на всех узлах кластера блокируются.

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

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

F.30.2.3. Служебные процессы расширения multimaster

mtm-monitor

Запускает все остальные служебные процессы для базы данных под управлением расширения multimaster. Это первый служебный процесс, который multimaster запускает при загрузке. На каждом узле кластера multimaster работает один служебный процесс mtm-monitor. Когда добавляется новый узел, mtm-monitor запускает процессы mtm-logrep-receiver и mtm-dmq-receiver, осуществляющие репликацию на этот узел. Если узел удаляется, mtm-monitor останавливает процессы mtm-logrep-receiver и mtm-dmq-receiver, обслуживающие данный узел. Процесс mtm-monitor управляет служебными процессами только на собственном узле.

mtm-logrep-receiver

Получает поток логической репликации с заданного узла-партнёра. При восстановлении этот процесс применяет все получаемые реплицируемые транзакции. При работе в штатном режиме процесс mtm-logrep-receiver передаёт транзакции пулу динамических фоновых процессов (см. mtm-logrep-receiver-dynworker). Число процессов mtm-logrep-receiver на каждом узле равняется числу узлов, с которыми он взаимодействует.

mtm-dmq-receiver

Получает подтверждения транзакций, переданных узлам-партнёрам, и контролирует соединения с этими узлами. Число процессов mtm-logrep-receiver на каждом узле равняется числу узлов, с которыми он взаимодействует.

mtm-dmq-sender

Собирает уведомления о транзакциях, применяемых на текущем узле, и передаёт их соответствующим процессам mtm-dmq-receiver на узлах-партнёрах. Для каждого экземпляра Postgres Pro запускается один процесс mtm-dmq-sender.

mtm-logrep-receiver-dynworker

Динамический процесс из пула для mtm-logrep-receiver. Применяет реплицированные транзакции, получаемые при работе в штатном режиме. Для каждого узла может запускаться до multimaster.max_workers таких процессов.

mtm-resolver

Узнаёт у всех партнёров состояние незаконченных транзакций, чтобы разобраться с ними согласно правилам 3PC. Этот служебный процесс работает только при восстановлении.

F.30.3. Установка и подготовка

Чтобы использовать multimaster, необходимо установить Postgres Pro Enterprise на всех узлах кластера. В состав Postgres Pro Enterprise включены все необходимые зависимости и расширения. Для обеспечения стабильной работы рекомендуется использовать два узла и рефери, как описано в Подраздел F.30.3.3.

F.30.3.1. Подготовка кластера

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

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

  1. Измените файл конфигурации postgresql.conf следующим образом:

    • Добавьте multimaster в переменную shared_preload_libraries:

      shared_preload_libraries = 'multimaster'

      Подсказка

      Если переменная shared_preload_libraries уже определена в postgresql.auto.conf, вам потребуется изменить её значение с помощью команды ALTER SYSTEM. За подробностями обратитесь к Подразделу 19.1.2. Заметьте, что в кластере с несколькими ведущими команда ALTER SYSTEM влияет только на конфигурацию того узла, на котором запускается.

    • Настройте параметры Postgres Pro, связанные с репликацией:

      wal_level = logical
      max_connections = 100
      max_prepared_transactions = 300 # max_connections * N
      max_wal_senders = 10            # как минимум N
      max_replication_slots = 10      # как минимум 2N
      wal_sender_timeout = 0

      здесь N — число узлов в вашем кластере.

      Вы должны сменить уровень репликации на logical, так как работа multimaster построена на логической репликации. Для кластера с N узлами разрешите минимум N передающих WAL процессов и слотов репликации. Так как multimaster неявно добавляет фазу PREPARE к COMMIT каждой транзакции, в качестве разрешённого количества подготовленных транзакций задайте N * max_connections. Параметр wal_sender_timeout следует отключить, так как multimaster использует собственную логику для обнаружения сбоев.

    • Убедитесь в том, что на каждом узле выделено достаточно фоновых рабочих процессов:

      max_worker_processes = 250 # (N - 1) * (max_connections + 3) + 3

      Например, для кластера с тремя узлами и ограничением max_connections = 100, механизму multimaster в пиковые моменты может потребоваться до 209 фоновых рабочих процессов: три всегда работающих служебных процесса (monitor, resolver, dmq-sender), по три процесса (walsender, mtm-receiver, dmq-receiver) для каждого соседнего узла и до 200 динамических процессов, осуществляющих репликацию (то есть по max_connections процессов для каждого соседнего узла). При выборе значения этого параметра не забывайте, что фоновые рабочие процессы могут быть нужны и другим модулям.

    • В зависимости от вашей схемы использования и конфигурации сети может потребоваться настроить и другие параметры multimaster. За подробностями обратитесь к Подразделу F.30.3.2.

  2. Запустите Postgres Pro Enterprise на всех узлах.

  3. Создайте базу данных mydb и пользователя mtmuser на каждом узле:

    CREATE USER mtmuser WITH SUPERUSER PASSWORD 'mtmuserpassword';
    CREATE DATABASE mydb OWNER mtmuser;

    Если вы хотите использовать аутентификацию по паролю, вам может быть полезен файл паролей.

    Вы можете опустить этот шаг, если у вас уже есть база данных, которую вы хотите реплицировать, но, тем не менее, для репликации рекомендуется создать отдельного пользователя с правами суперпользователя. В примерах ниже предполагается, что вы будете реплицировать базу mydb от имени пользователя mtmuser.

  4. Разрешите репликацию базы mydb на каждый узел кластера для пользователя mtmuser, как описывается в Разделе 20.1. При этом важно использовать метод аутентификации, удовлетворяющий вашим требованиям безопасности. Например, pg_hba.conf на узле node1 может содержать следующие строки:

    host replication mtmuser node2 md5
    host mydb mtmuser node2 md5
    host replication mtmuser node3 md5
    host mydb mtmuser node3 md5
  5. Подключитесь к любому узлу от имени пользователя БД mtmuser, создайте расширение multimaster в базе данных mydb и выполните функцию mtm.init_cluster(), указав первым аргументом строку подключения для текущего узла, а вторым — массив строк подключения для всех остальных узлов.

    Например, если вы хотите подключиться к узлу node1, выполните:

    CREATE EXTENSION multimaster;
    SELECT mtm.init_cluster('dbname=mydb user=mtmuser host=node1',
    '{"dbname=mydb user=mtmuser host=node2", "dbname=mydb user=mtmuser host=node3"}');
  6. Чтобы убедиться, что расширение multimaster активно, вы можете вызвать функции mtm.status() и mtm.nodes():

    SELECT * FROM mtm.status();
    SELECT * FROM mtm.nodes();

    Если в поле status появилось значение online и функция mtm.nodes показывает все узлы, значит ваш кластер успешно настроен и готов к использованию.

Подсказка

Если какие-либо данные должны присутствовать только на одном из узлов кластера, вы можете исключить таблицу с ними из репликации следующим образом:

SELECT mtm.make_table_local('table_name') 

F.30.3.2. Настройка параметров конфигурации

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

F.30.3.2.1. Установка тайм-аута для обнаружения сбоев

Для проверки доступности партнёров multimaster периодически опрашивает все узлы. Таймаут для обнаружения сбоев можно регулировать с помощью следующих переменных:

  • Переменная multimaster.heartbeat_send_timeout определяет интервал между опросами. По умолчанию её значение равно 200ms.

  • Переменная multimaster.heartbeat_recv_timeout определяет интервал для ответа. Если за указанное время ответ от какого-то узла не будет получен, он считается отключённым и исключается из кластера. По умолчанию её значение равно 2000ms.

Значение multimaster.heartbeat_send_timeout имеет смысл выбирать, исходя из типичных задержек ping между узлами. С уменьшением отношения значений recv/send сокращается время обнаружения сбоев, но увеличивается вероятность ложных срабатываний. При установке этого параметра учтите также типичный процент потерь пакетов между узлами кластера.

F.30.3.3. Установка отдельного узла-рефери

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

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

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

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

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

  1. Установите Postgres Pro Enterprise на узле, который вы планируете сделать рефери, и создайте расширение referee:

    CREATE EXTENSION referee;
  2. Разрешите в файле pg_hba.conf доступ к узлу-рефери.

  3. Настройте узлы, на которых будут находиться данные кластера, следуя указаниям в Подраздел F.30.3.1. Для более стабильной работы лучше ограничиться двумя узлами.

  4. На всех узлах кластера укажите строку подключения к рефери в файле postgresql.conf:

    multimaster.referee_connstring = строка_подключения

    Здесь строка_подключения задаёт параметры libpq, необходимые для обращения к рефери.

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

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

F.30.4. Администрирование кластера multimaster

F.30.4.1. Наблюдение за состоянием кластера

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

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

SELECT * FROM mtm.status();

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

SELECT * FROM mtm.nodes();

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

F.30.4.2. Обращение к отключённым узлам

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

F.30.4.3. Добавление узлов в кластер

Используя multimaster, вы можете добавлять или удалять узлы кластера, не останавливая службы баз данных. Чтобы добавить новый узел, вы должны загрузить на него данные, выполнив pg_basebackup на любом узле кластера, а затем запустить этот узел.

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

  1. Определите, какая строка подключения будет использоваться для обращения к новому узлу. Например, для базы данных mydb, пользователя mtmuser и нового узла node4 строка подключения может быть такой: "dbname=mydb user=mtmuser host=node4".

  2. В psql, подключённом к любому из работающих узлов, выполните:

    SELECT mtm.add_node('dbname=mydb user=mtmuser host=node4');

    Эта команда меняет конфигурацию кластера на всех узлах и создаёт слоты репликации для нового узла. Она также возвращает идентификатор node_id для нового узла, который потребуется для завершения настройки.

  3. Перейдите к новому узлу и скопируйте на него все данные с одного из работающих узлов:

    pg_basebackup -D каталог_данных -h node1 -U mtmuser -c fast -v

    pg_basebackup копирует весь каталог данных с node1, вместе с конфигурацией, и выводит последний LSN, воспроизведённый из WAL, например '0/12D357F0'. Это значение потребуется для завершения подключения.

  4. Запустите Postgres Pro на новом узле.

  5. На узле, с которого вы снимали базовую копию, выполните в psql:

    SELECT mtm.join_node(4, '0/12D357F0');

    здесь 4 — идентификатор node_id, возвращённый функцией mtm.add_node(), а '0/12D357F0' — значение LSN, выданное программой pg_basebackup.

F.30.4.4. Удаление узлов из кластера

Чтобы удалить узел из кластера:

  1. Вызовите функцию mtm.nodes(), чтобы узнать идентификатор узла, который нужно удалить:

    SELECT * FROM mtm.nodes();
  2. Вызовите функцию mtm.drop_node(), передав ей этот идентификатор в качестве параметра:

    SELECT mtm.drop_node(3);

    В результате будут удалены слоты репликации для узла 3 на всех узлах кластера и репликация на этот узел будет прекращена.

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

F.30.4.5. Удаление расширения multimaster

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

  1. Уберите multimaster из shared_preload_libraries и перезапустите Postgres Pro Enterprise.

  2. Удалите расширение multimaster и публикацию:

    DROP EXTENSION multimaster;
    DROP PUBLICATION multimaster;
  3. Просмотрите список существующих подписок с помощью команды \dRs и удалите те, имена которых начинаются с префикса mtm_sub_:

    \dRs
    DROP SUBSCRIPTION mtm_sub_имя_подписки;
  4. Просмотрите список существующих слотов репликации и удалите те, имена которых начинаются с префикса mtm_:

    SELECT * FROM pg_replication_slots;
    SELECT pg_drop_replication_slot('mtm_имя_слота');
  5. Просмотрите список существующих источников репликации и удалите те, имена которых начинаются с префикса mtm_:

    SELECT * FROM pg_replication_origin;
    SELECT pg_replication_origin_drop('mtm_имя_источника');
  6. Просмотрите список оставшихся подготовленных транзакций:

    SELECT * FROM pg_prepared_xacts;

    Вы должны зафиксировать или прервать эти транзакции, выполнив ABORT PREPARED ид_транзакции или COMMIT PREPARED ид_транзакции, соответственно.

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

F.30.4.6. Проверка согласованности данных на узлах кластера

Вы можете убедиться в том, что данные на всех узлах кластера одинаковые, воспользовавшись функцией 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)

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

F.30.5. Справка

F.30.5.1. Параметры конфигурации

multimaster.heartbeat_recv_timeout

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

По умолчанию: 2000 мс

multimaster.heartbeat_send_timeout

Интервал между контрольными обращениями, в миллисекундах. Процесс-арбитр рассылает широковещательные контрольные сообщения всем узлам для выявления проблем с соединениями.

По умолчанию: 200 мс

multimaster.max_workers

Максимальное число рабочих процессов walreceiver для каждого узла-партнёра.

Важно

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

По умолчанию: 100

multimaster.monotonic_sequences

Определяет режим генерирования последовательностей для уникальных идентификаторов. Эта переменная может принимать следующие значения:

  • false (по умолчанию) — идентификаторы на каждом узле генерируются, начиная с номера узла, и увеличиваются на число узлов. Например, в кластере с тремя узлами идентификаторы 1, 4 и 7 выделяются для объектов, создаваемых на первом узле, а 2, 5 и 8 резервируются для второго узла. Если число узлов в кластере изменяется, величина прироста идентификаторов корректируется соответственно.

  • true — генерируемая последовательность увеличивается монотонно во всём кластере. Идентификаторы узлов на каждом узле генерируются, начиная с номера узла, и увеличиваются на число узлов, но если очередное значение меньше идентификатора, уже сгенерированного на другом узле, оно пропускается. Например, в кластере с тремя узлами, если идентификаторы 1, 4 и 7 уже выделены на первом узле, идентификаторы 2 и 5 будут пропущены на втором. В этом случае первым идентификатором на втором узле будет 8. Таким образом следующий сгенерированный идентификатор всегда больше предыдущего, вне зависимости от узла кластера.

По умолчанию: false

multimaster.referee_connstring

Строка подключения для обращения к узлу-рефери. Если вы используете рефери, этот параметр нужно задать на всех узлах кластера.

multimaster.remote_functions

Содержит разделённый запятыми список имён функций, которые должны выполняться удалённо на всех узлах кластера вместо выполнения на одном и последующий репликации результатов.

multimaster.trans_spill_threshold

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

По умолчанию: 100 МБ

multimaster.break_connection

Разрывать соединения клиентов, подключённых к узлу, при отключении данного узла от кластера. Если этот параметр равен false, клиенты остаются подключёнными к узлу, но получают ошибку с сообщением о том, что узел отключён.

По умолчанию: false

F.30.5.2. Функции

mtm.init_cluster(my_conninfo text, peers_conninfo text[])

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

Аргументы:

  • my_conninfo — строка подключения для узла, на котором вы выполняете эту функцию. Используя эту строку, узлы-партнёры будут подключаться к данному узлу.

  • peers_conninfo — массив строк подключения для всех остальных узлов, которые будут добавляться в кластер.

mtm.add_node(connstr text)

Добавляет новый узел в кластер. Эта функция должна вызываться до того, как на этот узел будут загружаться данные с помощью pg_basebackup. mtm.add_node создаёт нужные слоты репликации для нового узла, так что с её помощью можно добавить узел в кластер под нагрузкой.

Аргументы:

  • connstr — строка подключения для нового узла. Например, для базы данных mydb, пользователя mtmuser и нового узла node4 строка подключения будет такой: "dbname=mydb user=mtmuser host=node4".

mtm.join_node(node_id int, backup_end_lsn pg_lsn)

Завершает настройку кластера после добавления нового узла. Эта функция должна вызываться после того, как добавленный узел будет запущен.

Аргументы:

  • node_id — идентификатор узла, добавляемого в кластер. Этот идентификатор выдаёт функция mtm.nodes() в поле id.

    backup_end_lsn — последний LSN базовой резервной копии, с которой инициализируется новый узел. Этот LSN будет отправной точкой для репликации данных после включения узла в кластер.

mtm.drop_node(node_id integer)

Исключает узел из кластера.

Если вы захотите продолжить использование этого узла вне кластера в независимом режиме, вам нужно будет удалить на этом узле расширение multimaster, как описано в Подраздел F.30.4.5.

Аргументы:

  • node_id — идентификатор удаляемого узла. Этот идентификатор выдаёт функция mtm.nodes() в поле id.

mtm.alter_sequences()

Исправляет уникальные идентификаторы на всех узлах кластера. Это может потребоваться после восстановления всех узлов из одной базовой копии.

mtm.status()

Показывает состояние расширения multimaster на текущем узле. Возвращает кортеж со следующими значениями:

  • node_id, integer — идентификатор этого узла.

  • status, text — состояние узла. Возможные значения: online (работает), recovery (восстановление), recovered (восстановлен), disabled (отключён).

  • n_nodes, integer — число узлов в кластере. Исходя из этого значения вычисляется количество активных узлов, составляющих большинство.

  • n_connected, integer — число подключённых узлов.

  • n_enabled, integer — число включённых узлов.

mtm.nodes()

Выдаёт информацию обо всех узлах в кластере. Возвращает кортеж со следующими значениями:

  • id, integer — идентификатор узла.

  • enabled, boolean — показывает, что узел полностью завершил восстановление и работает в штатном режиме. Узел может быть отключён, только если он не откликается на контрольные обращения в течение интервала heartbeat_recv_timeout. Когда узел начинает отвечать на контрольные обращения, multimaster может автоматически восстановить узел и вернуть его в активное состояние.

  • connected, boolean — показывает, подключён ли данный узел к текущему узлу.

  • sender_pid, integer — идентификатор процесса, передающего WAL.

  • receiver_pid, integer — идентификатор процесса, принимающего WAL.

  • receiver_status, text — состояние узла. Возможные значения: recovery (восстанавливается), recovered (восстановлен).

  • conninfo, text — строка подключения для этого узла.

mtm.make_table_local(relation regclass)

Останавливает репликацию для указанной таблицы.

Аргументы:

  • relation — таблица, которую вы хотели бы исключить из схемы репликации.

mtm.check_query(query_text text)

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

Аргументы:

  • query_text — текст запроса, который вы хотите выполнить на всех узлах для сравнения данных. Чтобы избежать ложных срабатываний, обязательно добавьте в этот запрос предложение ORDER BY.

mtm.get_snapshots()

Делает снимок данных на каждом узле кластера и возвращает идентификатор снимка. Снимки сохраняются до вызова mtm.free_snapshots() или до завершения текущего сеанса. Данную функцию вызывает mtm.check_query(query_text), отдельно вызывать её нет необходимости.

mtm.free_snapshots()

Удаляет снимки данных, сделанные функцией mtm.get_snapshots(). Данную функцию вызывает mtm.check_query(query_text), отдельно вызывать её нет необходимости.

F.30.6. Совместимость

F.30.6.1. Локальные и глобальные операторы DDL

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

  • ALTER SYSTEM

  • CREATE DATABASE

  • DROP DATABASE

  • REINDEX

  • CHECKPOINT

  • CLUSTER

  • LOAD

  • LISTEN

  • CHECKPOINT

  • NOTIFY

F.30.7. Авторы

Postgres Professional, Москва, Россия.

F.30.7.1. Благодарности

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

Протокол трёхфазной фиксации транзакций E3PC описан в следующей работе:

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