Перейти к основному содержимому

Репликация

Компонент Pangolin Manager использует потоковую репликацию СУБД Pangolin. По умолчанию репликация настраивается в асинхронном режиме. Выбор схемы репликации зависит от требований к доступности и сохранности данных.

Настройка резервного сервера начинается с установки параметра standby_mode = 'on'. Также доступны дополнительные опции, например описание слота репликации.

Асинхронная репликация​

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

При сбое ведущего узла Pangolin Manager автоматически выбирает новую реплику в качестве ведущего. Транзакции, которые не успели примениться на новой реплике, теряются.

Количество транзакций, которые могут быть потеряны, контролируется параметром maximum_lag_on_failover. Поскольку позиция журнала транзакций ведущего узла определяется не в реальном времени, фактический объем потерянных данных при отказе составляет максимально допустимое значение maximum_lag_on_failover байт журнала транзакций плюс данные, записанные за последние ttl секунд (в среднем loop_wait в 2 секунды).

Режим асинхронной репликации настраивается параметром Pangolin Manager:

synchronous_mode: false

По умолчанию при выборе лидера Pangolin Manager не учитывает текущую временную шкалу реплик. Для предотвращения выбора узла с отличающейся временной шкалой в качестве нового лидера используется параметр check_timeline:

check_timeline: true

Стандартная синхронная репликация СУБД Pangolin​

В режиме стандартной синхронной репликации транзакции, изменяющие данные, принимаются ведущим узлом, но не фиксируются до того момента, когда все изменения получены репликой и записаны на диск (при synchronous_commit = on). Таким образом возникает задержка, которая может расти в случае проблемы на стороне реплики. В данном режиме обеспечивается более высокий уровень надежности при уменьшении производительности. При этом Pangolin Manager рассматривает его как асинхронный и действует соответственно.

Количество и имена синхронных реплик определяется параметром synchronous_standby_names. Если значение параметра не установлено, то синхронная репликация не включается.

Режим синхронной репликации СУБД Pangolin включается с помощью параметров:

postgresql:
  parameters:
    synchronous_commit: "on"
    synchronous_standby_names: "*"
Примечание

В режиме стандартной синхронной репликации СУБД Pangolin рекомендуется использовать не менее двух реплик, чтобы сохранить доступность на запись, если произойдет сбой на каком-либо узле.

Если будут одновременно недоступны ведущий узел и синхронная реплика, Pangolin Manager автоматически выдвинет на роль ведущего третий узел — асинхронную реплику. Выполнится отказ на асинхронную реплику. Система возобновит обычную работу. Транзакции, которые отсутствовали на третьем узле, будут утеряны.

Синхронный режим Pangolin Manager​

Pangolin Manager предоставляет два режима работы синхронной репликации (в предыдущих случаях он работает в асинхронном режиме).

Нестрогий режим синхронной репликации​

Режим нестрогой синхронной репликации (режим по умолчанию) включается параметром:

synchronous_mode: true

Поведение в режиме нестрогой синхронной репликации:

  1. При недоступности реплики (например, после перезагрузки кластера) Pangolin Manager выбирает обеспечение доступности на изменение данных и переключает ведущий узел на работу в асинхронном режиме (репликация данных не контролируется). При этом ведущий узел продолжает принимать транзакции на изменение данных. Если на реплике происходит сбой в процессе работы, то фиксация транзакций заблокируется на некоторое время до переключения ведущего узла в режим работы standalone (с помощью Pangolin Manager). В случае ручного останова или перезагрузки реплики прекращения фиксации транзакций не происходит, так как перед остановом реплика посылает сигнал ведущему узлу об освобождении себя от статуса резервного сервера (stand-by).

  2. При сбое ведущего узла Pangolin Manager не позволит переключиться на реплику, если реплика не содержит данные всех зафиксированных транзакций (например, если приложение использует асинхронный коммит на уровне транзакции). Также не происходит переключения, если нет подходящей синхронной реплики. Таким образом, в случае сбоя ведущего узла переключение на реплику может не произойти и кластер будет недоступен на запись. Администратор может выполнить переключение вручную с помощью команды failover, хотя это приведет к потере данных незафиксированных транзакций. Когда хост ведущего узла снова становится доступным после сбоя, то ведущий узел автоматически устанавливается обратно в своей роли (если до этого не произошло ручного переключения). Такой алгоритм действий позволяет использовать синхронную репликацию на двух узлах.

Строгий режим синхронной репликации​

Режим строгой синхронной репликации — максимальный уровень защиты данных, который достигается при помощи Pangolin Manager. Включается параметром:

synchronous_mode: true
synchronous_mode_strict: true

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

Даже в режиме строгой синхронной репликации возможна потеря данных:

  • Из-за одновременной потери ведущего узла и реплики.
  • Использование асинхронного коммита на уровне приложения.
  • Из-за особенностей реализации синхронной репликации в СУБД Pangolin. В случае сбоя фонового процесса СУБД (например, из-за тайм-аута) в момент ожидания подтверждения от репликации изменения данных транзакции могут стать видимыми другим фоновым процессам. Так как эти изменения еще не синхронизировались с репликой, они могут быть потеряны в случае выбора нового ведущего узла.

Узел без синхронизации​

Узел можно исключить из кандидатов на синхронную репликацию, установив тег nosync в значение true:

tags:
  nosync: true

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

Количество синхронных узлов​

Параметр synchronous_node_count управляет количеством синхронных резервных баз данных. По умолчанию равен 1. Параметр не действует, если synchronous_mode установлен в false.

synchronous_node_count: 1

При включенном режиме Pangolin Manager управляет точным количеством синхронных резервных баз данных на основе параметра synchronous_node_count и корректирует состояние в DCS и synchronous_standby_names по мере присоединения и отключения участников.

Переключение режимов репликации​

Режим асинхронной репликации​

  1. Установите параметр synchronous_mode в значение false.

    При этом Pangolin Manager сбросит параметр synchronous_standby_names на всех узлах. Параметр synchronous_commit останется в значении 'on', однако при пустом списке synchronous_standby_names он будет действовать только локально.

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml edit-config $CLUSTERNAME --set synchronous_mode="false" --set synchronous_mode_strict="false" --force

    Пример вывода diff:

    ---
    +++
    @@ -12,6 +12,6 @@
       use_pg_rewind: true
       use_slots: true
     retry_timeout: 60
    -synchronous_mode: true
    +synchronous_mode: false
    -synchronous_mode_strict: true
    +synchronous_mode_strict: false
     ttl: 130

    Configuration changed

  2. Проверьте статус узлов кластера. Значение роли Replica узла реплики означает асинхронную репликацию.

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

    Пример вывода:

    + Cluster: $CLUSTERNAME (<cluster_id>) --+-----------+-----+-------------+-----+------------+-----+
    | Member      | Host           | Role    | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
    +-------------+----------------+---------+-----------+-----+-------------+-----+------------+-----+
    | srv1        | 127.0.0.1:5432 | Leader  | running   |   7 |             |     |            |     |
    | srv2        | 127.0.0.1:5433 | Replica | running   |   7 |   0/C000000 |   0 |  0/C000000 |   0 |
    +-------------+----------------+---------+-----------+-----+-------------+-----+------------+-----+

  3. Проверьте значение параметров synchronous_commit ('on') и synchronous_standby_names (null) с помощью команды SHOW (или SQL-запроса для краткости). Проверьте статус репликации с точки зрения СУБД Pangolin (async — асинхронная).

    SELECT name, setting FROM pg_settings WHERE name LIKE '%synchronous%';

    Пример вывода:

               name            | setting
    ---------------------------+---------
     synchronous_commit        | on
     synchronous_standby_names |
    (2 rows)
    SELECT application_name, state, sync_state FROM pg_stat_replication;

    Пример вывода:

       application_name   |   state   | sync_state
    ----------------------+-----------+------------
     srv2                 | streaming | async
    (1 row)

Режим стандартной синхронной репликации СУБД Pangolin​

  1. Отредактируйте файл конфигурации /etc/pangolin-manager/postgres.yml и установите параметры synchronous_commit: "on" и synchronous_standby_names: "*". Параметр Pangolin Manager synchronous_mode оставьте без изменений (false).

    После применения параметров на уровне СУБД Pangolin репликация переключится в синхронный режим, а вот на уровне кластера логика обработки сбоев репликации останется прежней.

    postgresql:
      parameters:
        synchronous_commit: 'on'
        synchronous_standby_names: "*"

  2. Примените изменения:

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml reload $CLUSTERNAME --force

    Пример вывода:

    + Cluster: $CLUSTERNAME (<cluster_id>) --+-----------+-----+-------------+-----+------------+-----+
    | Member      | Host           | Role    | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
    +-------------+----------------+---------+-----------+-----+-------------+-----+------------+-----+
    | srv1        | 127.0.0.1:5432 | Leader  | running   |   7 |             |     |            |     |
    | srv2        | 127.0.0.1:5433 | Replica | running   |   7 |   0/C000000 |   0 |  0/C000000 |   0 |
    +-------------+----------------+---------+-----------+-----+-------------+-----+------------+-----+
    Reload request received for member srv2 and will be processed within 10 seconds
    Reload request received for member srv1 and will be processed within 10 seconds

  3. Проверьте параметры:

    SHOW synchronous_standby_names;

    Пример вывода:

     synchronous_standby_names
    ---------------------------
     *
    (1 row)
    SELECT application_name, state, sync_state FROM pg_stat_replication;

    Пример вывода:

       application_name   |   state   | sync_state
    ----------------------+-----------+------------
     srv2                 | streaming | sync
    (1 row)

Режим нестрогой синхронной репликации​

  1. Установите параметр synchronous_mode в значение true.

    Pangolin Manager автоматически выберет одну синхронную реплику (или наберет группу, если включено) и применит без перезапуска новый параметр synchronous_standby_names к СУБД Pangolin на ведущем узле. На реплике также включится synchronous_commit=on, а вот synchronous_standby_names будет очищен.

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml edit-config $CLUSTERNAME --set synchronous_mode="true" --force

    Пример вывода diff:

    ---
    +++
    @@ -12,6 +12,6 @@
      use_pg_rewind: true
      use_slots: true
     retry_timeout: 60
    -synchronous_mode: false
    +synchronous_mode: true
     synchronous_mode_strict: false
     ttl: 130

    Configuration changed

  2. Проверьте статус кластера:

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

    Пример вывода:

    + Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+-----+-------------+-----+------------+-----+
    | Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
    +-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
    | srv1        | 127.0.0.1:5432 | Leader       | running   |   7 |             |     |            |     |
    | srv2        | 127.0.0.1:5433 | Sync Standby | running   |   7 |   0/C000000 |   0 |  0/C000000 |   0 |
    +-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+

  3. Проверьте параметры:

    SHOW synchronous_standby_names;

    Пример вывода:

     synchronous_standby_names
    ---------------------------
     "srv2"
    (1 row)
    SELECT application_name, state, sync_state FROM pg_stat_replication;

    Пример вывода:

       application_name   |   state   | sync_state
    ----------------------+-----------+------------
     srv2                 | streaming | sync
    (1 row)

Режим строгой синхронной репликации​

  1. Установите параметр synchronous_mode_strict в значение true.

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml edit-config $CLUSTERNAME --set synchronous_mode_strict="true" --force

    Пример вывода diff:

    ---
    +++
    @@ -13,5 +13,5 @@
      use_slots: true
     retry_timeout: 60
     synchronous_mode: true
    -synchronous_mode_strict: false
    +synchronous_mode_strict: true
     ttl: 130

    Configuration changed

  2. Проверьте статус кластера:

    $ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

    Пример вывода:

    + Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+-----+-------------+-----+------------+-----+
    | Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
    +-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
    | srv1        | 127.0.0.1:5432 | Leader       | running   |   7 |             |     |            |     |
    | srv2        | 127.0.0.1:5433 | Sync Standby | running   |   7 |   0/C000000 |   0 |  0/C000000 |   0 |
    +-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+

Тестирование работы строгой синхронной репликации:

Для проверки измените параметр на стороне реплики, чтобы она не могла запуститься. Затем перезапустите Pangolin Manager. После этого реплика не запустится. На стороне ведущего узла выполните команду CREATE TABLE, которая не сможет завершиться до тех пор, пока реплика не восстановит работоспособность.

На стороне реплики измените pg_hba.conf для блокировки подключения.

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

Пример вывода:

+ Cluster: $CLUSTERNAME (<cluster_id>) --+---------------+-----+-------------+---------+------------+-----------+
| Member      | Host           | Role    | State         | TL  | Receive LSN | Lag     | Replay LSN | Lag       |
+-------------+----------------+---------+---------------+-----+-------------+---------+------------+-----------+
| srv1        | 127.0.0.1:5432 | Leader  | running       |  7  |             |         |            |           |
| srv2        | 127.0.0.1:5433 | Replica | start failed  |     |             | unknown |            |   unknown |
+-------------+----------------+---------+---------------+-----+-------------+---------+------------+-----------+

На стороне ведущего узла выполнение CREATE TABLE «подвиснет»:

CREATE TABLE sch1.test1(id integer);

После восстановления конфигурации реплики и ее перезапуска команда CREATE TABLE завершится успешно.

Мониторинг состояния репликации​

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

$ pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLUSTERNAME

Пример вывода:

+ Cluster: $CLUSTERNAME (<cluster_id>) -------+-----------+-----+-------------+-----+------------+-----+
| Member      | Host           | Role         | State     | TL  | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+
| srv1        | 127.0.0.1:5432 | Leader       | running   |   7 |             |     |            |     |
| srv2        | 127.0.0.1:5433 | Sync Standby | running   |   7 |   0/C000000 |   0 |  0/C000000 |   0 |
+-------------+----------------+--------------+-----------+-----+-------------+-----+------------+-----+

Значение роли Sync Standby указывает на синхронную реплику. Значение Replica указывает на асинхронную реплику.

Для проверки параметров репликации на уровне СУБД Pangolin выполните SQL-запрос:

SELECT name, setting FROM pg_settings WHERE name LIKE '%synchronous%';

Пример вывода:

           name            | setting
---------------------------+---------
 synchronous_commit        | on
 synchronous_standby_names | "srv2"
(2 rows)

Для проверки состояния репликации с точки зрения СУБД Pangolin:

SELECT application_name, state, sync_state FROM pg_stat_replication;

Пример вывода:

   application_name   |   state   | sync_state
----------------------+-----------+------------
 srv2                 | streaming | sync
(1 row)

Значение sync_state = sync указывает на синхронную репликацию, async — на асинхронную.