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

Используйте эту инструкцию для уменьшения значений следующих параметров:

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

В системах Linux для минимальной конфигурации узла-рефери в режиме referee требуется 1 ядро ЦП и 1 ГБ ОЗУ. Этого достаточно для участия в выборах.

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

Для операционных систем, отличных от Linux, необходимо выделять ресурсы в соответствии с минимальными требованиями используемой операционной системы.

При добавлении рефери, утилита pg_basebackup создаёт частичную резервную копию лидера. Это значит, что, по умолчанию, на рефери с лидера копируются только база данных biha_db и системные таблицы. База данных postgres и пользовательские данные не копируются. Это сделано намеренно для уменьшения потребления ресурсов.

Однако некоторые утилиты и системы мониторинга используют базу данных postgres для подключения к узлам. Если необходимо, чтобы база данных postgres присутствовала на рефери, вы можете указать параметр --referee-with-postgres-db при добавлении узла в режиме referee или referee_with_wal. Этот параметр копирует на рефери базу данных postgres со всеми объектами. Для рефери в режиме referee_with_wal также применяются записи WAL, относящиеся к базе данных postgres. Это значит, что все новые объекты, созданные в базе данных postgres, будут также созданы на рефери в режиме referee_with_wal.

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

Например, можно распределить узлы трёхузлового BiHA-кластера по трём разным центрам обработки данных, где можно быстро переключиться на любого из последователей в случае отказа лидера:

Можно также разместить лидера и двух последователей BiHA-кластера в ЦОДе 1, а дополнительного Последователя 3 в удалённом ЦОДе 2 использовать как георезерв. Последователь 3 работает лишь в качестве резерва и не может ни участвовать в выборах, ни стать лидером:

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

Решение BiHA предоставляет ряд параметров, таких как biha.max_replicas и biha.preferred_roles, предназначенных для автоматической настройки каскадной репликации. После настройки этих параметров каждый узел кластера независимо выбирает свой источник репликации. В случае обновления топологии кластера, например, изменения лидера или количества узлов, каскадная репликация устанавливается автоматически.

За подробной информацией о том, как настроить каскадную репликацию в BiHA-кластере, обратитесь к Настройка каскадной репликации.

На следующей схеме изображён пример каскадного BiHA-кластера, состоящего из пяти узлов, распределённых между двумя центрами обработки данных:

BiHA-кластер на схеме выше работает следующим образом:

Предположим, что произошёл отказ Лидера:

Каскадная репликация автоматически перенастраивается следующим образом:

Решение BiHA позволяет создать многоуровневый геораспределённый и катастрофоустойчивый кластер (GDBiHA) для обеспечения эффективной работы 24/7 при высоких нагрузках. Кластер GDBiHA разделён на сегменты — логические узлы, которые объединяют один или несколько узлов кластера BiHA. Сегменты расположены в географически удалённых центрах обработки данных и имеют собственные системы выборов: параметры biha.minnodes и biha.nquorum настраиваются на каждом сегменте и наследуются узлами этих сегментов.

На следующей схеме изображена типичная структура кластера GDBiHA, распределённого между двумя центрами обработки данных:

Кластер GDBiHA на схеме выше состоит из следующих компонентов:

Узлы в GDBiHA-кластере могут работать на разных уровнях. Физические узлы (с идентификаторами 1-6) работают на уровне 1 (физический уровень). Сегменты (с идентификаторами 111 и 222) работают на уровне 2 (сегментный уровень). Кластер (с идентификатором 1111) работает на уровне 3 (кластерный уровень).

Чтобы проверить, на каком уровне работает узел, а также посмотреть другие детали конфигурации всех узлов, вызовите функцию biha.config:

  id  | term | nquorum | minnodes | heartbeat_send_period | heartbeat_max_lost | no_wal_on_follower | sync_standbys_min | priority | can_be_leader | can_vote |  mode   | proxima_status |      name      | repl_pref_roles | max_replicas | config_version | level | parent_id 
------+------+---------+----------+-----------------------+--------------------+--------------------+-------------------+----------+---------------+----------+---------+----------------+----------------+-----------------+--------------+----------------+-------+-----------
    1 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_1    | L               |   2147483647 |             17 |     1 |       111
    2 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_2    | L               |   2147483647 |             17 |     1 |       111
    3 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_3    | L               |   2147483647 |             17 |     1 |       111
    4 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_4    | L               |   2147483647 |             17 |     1 |       222
    5 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_5    | L               |   2147483647 |             17 |     1 |       222
    6 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_6    | L               |   2147483647 |             17 |     1 |       222
  111 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_111  | L               |   2147483647 |             17 |     2 |      1111
  222 |    1 |       2 |        2 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_222  | L               |   2147483647 |             17 |     2 |      1111
 1111 |    1 |       1 |        1 |                  1000 |                 10 |              20000 |                -2 |       -1 | t             | t        | regular |              0 | biha_node_1111 | L               |   2147483647 |             17 |     3 |          
(9 rows)

Вы можете настраивать узлы, сегменты и кластер GDBiHA с помощью функций расширения biha.

За подробной информацией о развёртывании кластера GDBiHA обратитесь к Подготовка многоуровневого геораспределённого и катастрофоустойчивого кластера BiHA (GDBiHA).