Pull to refresh
10
Karma
0
Rating
Павел Бобровников @pbobrovnikov

Пользователь

  • Followers 5
  • Following

Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync

Sevchik403, настраивал как с отдельно стоящими PGPOOL-II (2 хоста+WatchDog), так и с PGPOOL-II непосредственно на самих хостах с БД.
Когда мастер падал, отрабатывал Failover.sh на слэйве — создавал trigger_file и слэйв становился мастером — это билет в один конец, т.е. мастер упавший придется восстанавливать ручками, например, через pg_basebackup со слэйва, потому как если упавший мастер поднять — вуаля! и у нас 2 мастера (во всяком случае тесты показывали именно такое).

Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync

Вижу, что split braint — больная тема). Диски — FC. В конфигурациях Active/Active такое быть может, несомненно. В Active/Passive — отнюдь. Единственное, что может быть в Active/Passive — база уйдет in recovery в момент переезда, когда данные не успеют сброситься на диск, но для этого надо тюнинг postgresql.conf (fsync, sync.commit)
Дабы закрыть тему со split braint, предлагаю Вам поднять на виртуалах данную конфигурацию и проверит все на деле.

Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync

в статье указано, что сделать чтобы это не происходило.
Когда группа STARTED на конкретном хосте в кластере, на другой ноде — данного lvm диска даже не числится. Диском управляет кластер — где группа, там и диск.
Проверено.

Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync

Здесь не идет речи о split brain, так как в один момент времени инстанс PostgreSQL крутится на одном хосте, репликация не используется и группа представляется как единый сервис и все операции записи/чтения идут в одно место.
В случае выхода из строка VIP (моргнет сеть) либо сервиса, вся группа переедет на другую ноду.

PostgreSQL 9.3 + Pgpool-II

Всё верно — изначально архитектура предполагала наличие второго Pgpool, они работали перекрестно и это было настроено, судя по разделу «WatchDog», где виртуальный IP-бегает между двумя Pgpool. Затем при тестировании Online Recovery, я убрал второй Pgpool из-за предостережения, которое нашел в мануале: «Note that there is a restriction about online recovery. If pgpool-II itself is installed on multiple hosts, online recovery does not work correctly, because pgpool-II has to stop all clients during the 2nd stage of online recovery. If there are several pgpool hosts, only one will have received the online recovery command and will block connections.»

PostgreSQL 9.3 + Pgpool-II

Изначально была задача разобраться в решениях по отказоустойчивости в PostgreSQL. Сначала настроил Stream + Pgpool — чаще всего такая архитектура встречается в Интернете. Здесь тебе и select-ы на все ноды, но запись в одно место. Но потом захотелось попробовать писать сразу везде (некий мультимастер). И как оказалось, это мало кто использует, видимо как раз потому, что доверяют больше внутренним механизмам, это видимо и есть mainstream. Просто когда у тебя много транзакций в базе, генерация wal просто сумасшедшая, но это получается дешевле чем проигрывать в потере SQL-запросов (цитата от О.Бартунова) Захотелось раскурить pgpool — настроить его можно, поддерживать можно, но вот если одна из нод останавливается (при этом система продолжит, конечно, работать)по любой причине начинаются танцы с бубном.
Какие у Вас архитектуры по отказоустойчиовсти? pgBouncer + Stream?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity