https://docs.mitigator.ru/v26.04/tags/pgfailover/ Recent content in Pgfailover on BIFIT Mitigator Hugo -- gohugo.io ru https://docs.mitigator.ru/v26.04/kb/cluster/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/kb/cluster/ MITIGATOR может быть собран в кластер различных конфигураций, с разным набором подсистем и их взаимосвязей в зависимости от решаемой задачи и ограничений. В статье перечислены ключевые термины, описывающие кластеризацию MITIGATOR на различных уровнях. Уровни кластеризации В таблице представлен пример кластера из четырех экземпляров MITIGATOR, в котором на разных уровнях экземпляры выполняют разные роли. Под экземпляром понимается устройство, на котором развернута одна или несколько подсистем MITIGATOR. Обычно на экземпляре как минимум развернут Backend, но в некоторых случаях это могут быть другие подсистемы, например Colleсtor или Graphite. https://docs.mitigator.ru/v26.04/install/multi/failover/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/install/multi/failover/ Дальнейшие шаги предполагают, что экземпляр MITIGATOR уже установлен. В противном случае предварительно выполните установку одним из следующих способов. Перед настройкой кластера необходимо настроить виртуальную сеть (VPN). Для ее работы нужна сетевая связность между экземплярами. Подробные сведения по настройке и необходимым доступам описаны по ссылке. В целях отказоустойчивости синхронизированные копии БД должны физически храниться на разных серверах (реплицироваться). При данной схеме реплики БД хранятся на тех же серверах, где работают экземпляры MITIGATOR. https://docs.mitigator.ru/v26.04/install/multi/hybrid/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/install/multi/hybrid/ При сборке кластера схемы внедрения могут быть скомбинированы. Пример: Отказоустойчивое хранилище с дополнительными узлами фильтрации При такой схеме внедрения копии БД хранятся на разных серверах (реплицируются), но количество реплик БД меньше, чем количество экземпляров MITIGATOR в кластере. Часть экземпляров обращается к удаленным базам по портам TCP: 8888, 2003, 3080, 5432. В данном примере graphite и LOGAN размещены на отдельных серверах. Для корректной работы системы всем обработчикам пакетов, должно быть доступно одинаковое количество системных ресурсов. https://docs.mitigator.ru/v26.04/kb/pgfailover/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.mitigator.ru/v26.04/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.