Дано:
Встала задача обеспечить отказоустойчивость БД postgres.
Сейчас БД крутится на 1 узле, нагрузка небольшая, но БД должна быть доступна всегда + нельзя терять старые данные.
Требуется:
1) Настроить потоковую репликацию на 2 узел
2) Настроить отказоустойчивость, т.е. при смерти одной из нод, чтобы клиенты подключались ко второй.
Хотел бы проверить, правильно ли я понимаю принцип работы различных решений для High Availibility кластера postgres. Несколько дней изучал тему, выделил для себя наиболее популярные и достойные решения, 2 шт:
Решения а) примитивный вариант
pg_auto_failover + HAProxy + keepalived
- pg_auto_failover реплицирует, мониторит, назначает мастера в кластере;
- HAProxy + keepalived мониторит и перекидывает Virtual IP на IP текущего мастера
в) продвинутый вариант
Patroni + etcd + haproxy + keepalived
- patroni реплицирует, управляет кластером postgres;
- etcd в качестве кластера-арбитра для мониторинга и выбора мастера;
- HAProxy + keepalived мониторит и перекидывает Virtual IP на IP текущего мастера
Вопросы:
1) Есть ли ошибки в вышеописанном?
2) В первом варианте сохраняется единая точка отказа - узел с pg_auto_failover?
3) А в свою очередь HAProxy + keepalived могут работать в режиме кластера на нескольких машинах? Или они в первом варианте тоже запускаются в одном экземпляре и узел с ними является точкой отказа?
4) В обоих случаях можно настроить, чтобы клиенты подключались не только к мастеру, но и к реплике?
5) Для стабильно работающей базы без перегрузов хватит и примитивного варианта, в то время как второй вариант для более высокого уровня HA?
6) Какие фундаментальные и самые важные различия у первого и второго варианта?
Единая точка отказа - это автоматика failover базы как таковая. Там где такое есть - число аварий возрастает, а не уменьшается. Не забудьте учесть хоть как-нибудь в планах риски дополнительных аварий по причине именно добавленного autofailover. А так же сопутствующей возросшей сложности администрирования. Я предупредил.
Средний
