https://docs.mitigator.ru/v26.08/tags/pgfailover/ Hugo ru https://docs.mitigator.ru/v26.08/kb/cluster/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/kb/cluster/ MITIGATOR может быть собран в кластер различных конфигураций, с разным набором подсистем и их взаимосвязей в зависимости от решаемой задачи и ограничений. В статье перечислены ключевые термины, описывающие кластеризацию MITIGATOR на различных уровнях. Уровни кластеризации В таблице представлен пример кластера из четырех экземпляров MITIGATOR, в котором на разных уровнях экземпляры выполняют разные роли. Под экземпляром понимается устройство, на котором развернута одна или несколько подсистем MITIGATOR. Обычно на экземпляре как минимум развернут Backend, но в некоторых случаях это могут быть другие подсистемы, например Collector или Graphite. https://docs.mitigator.ru/v26.08/install/multi/failover/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/install/multi/failover/ Дальнейшие шаги предполагают, что экземпляр MITIGATOR уже установлен. В противном случае предварительно выполните установку одним из следующих способов. Перед настройкой кластера необходимо настроить виртуальную сеть (VPN). Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке. В целях отказоустойчивости синхронизированные копии БД должны физически храниться на разных серверах (реплицироваться). При данной схеме реплики БД хранятся на тех же серверах, где работают экземпляры MITIGATOR. Это позволяет сэкономить ресурсы и не требует знаний по настройке PostgreSQL. https://docs.mitigator.ru/v26.08/install/multi/hybrid/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/install/multi/hybrid/ При сборке кластера схемы внедрения могут быть скомбинированы. Пример: Отказоустойчивое хранилище с дополнительными узлами фильтрации При такой схеме внедрения копии БД хранятся на разных серверах (реплицируются), но количество реплик БД меньше, чем количество экземпляров MITIGATOR в кластере. Часть экземпляров обращается к удаленным базам по портам TCP: 8888, 2003, 3080, 5432. В данном примере graphite и LOGAN размещены на отдельных серверах. https://docs.mitigator.ru/v26.08/kb/pgfailover/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.08/kb/pgfailover/ pgfailover наблюдает за состоянием кластера PostgreSQL и выступает для клиентов как TCP-прокси к текущему Primary. При смене Primary pgfailover разрывает соединения с клиентами, и они должны переподключиться. Параметры подключения задаются через переменные окружения с префиксом PGFAILOVER_: export PGFAILOVER_BIND_ADDRESS=":5432" export PGFAILOVER_SERVERS="postgres://repuser@pg0.example.com/database?sslmode=disable&connect_timeout=5 postgres://repuser@pg1.example.com/database?sslmode=disable&connect_timeout=5" ./pgfailover Роль сервера (Primary/Standby) проверяется pg_is_in_recovery() по умолчанию раз в 5 секунд (PGFAILOVER_INTERVAL), количество попыток подключения регулируется переменной PGFAILOVER_ATTEMPTS (по умолчанию 1). pgfailover может автоматически переводить локальный PostgreSQL в Primary. Адрес локальной БД задаётся переменной окружения PGFAILOVER_PROMOTION_ADDRESS и должен совпадать с хостом одной из записей PGFAILOVER_SERVERS. Когда с Primary пропадает связь, pgfailover переводит в Primary первый по порядку Standby в PGFAILOVER_SERVERS. Если PGFAILOVER_PROMOTION_ADDRESS не задан, перевод в Primary отключён.