Правильное управление PGPool II
В настоящее время у меня есть сайт с одним сервером баз данных Postgres. Это только для определенного количества пользователей (менее десяти), но для этого требуется максимально возможное время безотказной работы.
Я хотел бы какой-то автоматический переход на другой ресурс для базы данных.
Итак, я подумал что-то вроде: один сервер под управлением PGPool II, один под управлением Postgres в качестве главного, другой под управлением Postgres в качестве подчиненного. Но затем, если, где бы ни работал PGPool, внезапно теряет питание (или умирает, или что-то еще), возникает одна точка отказа, и все это рушится.
Есть ли решение, предполагая, что передать это кому-то другому невозможно?
1 ответ
Одно можно сказать наверняка: должно быть запущено как минимум две машины pgpool, От того, как вы этого достигнете, зависит - не существует универсального решения для всех случаев. Если у вас есть веб-приложение, то вы также должны запустить веб-приложение как минимум на двух компьютерах, чтобы вы могли сделать что-то вроде этого:
+----------+ +---------+
| pgmaster | | pgslave |
+----------+ +---------+
| |
+----------+-------------+-----------+
| |
+-----|----+ +-----|----+
| pgpool | | pgpool |
| | | | | |
| webapp | | webapp |
+-----|----+ +-----|----+
| |
internet internet
(В этом случае вам также понадобится какое-то переключение на стороне клиента - тот, который я пометил как "интернет".)
Если, с другой стороны, вам действительно нужно не высокодоступное веб-приложение (или аналогичная служба), а высокодоступный postgresql (к которому любой клиент может подключиться в любое время), то альтернативой является
+----------+ +---------+
| pgmaster | | pgslave |
+----------+ +---------+
| |
+----------+-------------+-----------+
| |
+-----|----+ +-----|----+
| pgpool | | pgpool | (standby)
+-----|----+ +-----|----+
| |
Failover
IP address
|
client
pgpoolв этом случае также может находиться на той же машине, что и базы данных. Что важно, так это то, что вам нужен какой-то вид сбоя, если IP-адрес может быть keepalived, но точные доступные решения зависят от сетевых деталей более низкого уровня центра обработки данных, который вы используете (например, keepalived не может работать в Hetzner, поскольку у них есть другой способ переключения отказоустойчивых IP-адресов). Также обратите внимание, что в этом случае подключенные клиенты, вероятно , отключатся в случае сбоя, но они смогут немедленно восстановить соединение.
Также обратите внимание, что есть и другие трудности, одна из которых заключается в том, что вы не можете исключить разбиение сети, когда обе машины PostgreSQL будут работать и подключаться, но они каким-то образом потеряют связь друг с другом, поэтому каждый из них будет думать другой мертв, и поэтому каждый решит стать хозяином. Для решения этой проблемы мне известны три решения: 1) STONITH, для которого требуется специальное оборудование; 2) Кворумы, для которых требуется специальное программное обеспечение (например, Corosync/ кардиостимулятор); 3) Ручное аварийное переключение (администраторы получают уведомления, и система не работает, пока они не решат, как это исправить). Тем не менее, может быть не слишком сложно установить кворум, если вы используете мою предложенную схему выше, но с тремя pgpoolс вместо двух; но я не помню, если pgpool поддерживает это.
Итог: высокая доступность может быть сложной и дорогой. Тщательно изучить возможность избежать этого в целом. Если вы не можете, будьте готовы много учиться, много проектировать и много перепроектировать, и знайте, что это займет много времени.