Назад | Перейти на главную страницу

Правильное управление PGPool II

В настоящее время у меня есть сайт с одним сервером базы данных Postgres. Это только для избранного числа пользователей (менее десяти), но для этого требуется максимально возможное время безотказной работы.

Я хотел бы какой-то автоматический переход на другой ресурс для базы данных.

Итак, я думал примерно так: на одном сервере работает PGPool II, на одном работает Postgres как главный, на одном Postgres как подчиненный. Но затем, если где бы ни был запущен PGPool, внезапно пропадает питание (или умирает, или что-то еще), возникает единственная точка отказа, и все это выходит из строя.

Есть ли решение, если предположить, что передать это кому-то другому невозможно?

Одно можно сказать наверняка: должно быть запущено как минимум две машины. 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) Ручное переключение при отказе (администраторы получают уведомление, и система ломается, пока они не решат, как это исправить). Однако создать кворум не так уж сложно, если вы воспользуетесь предложенной мной выше схемой, но с тремя pgpools вместо двух; но я не помню, если pgpool поддерживает это.

Итог: высокая доступность может быть сложной и дорогостоящей. Внимательно изучите возможность того, чтобы этого избежать. Если вы не можете, будьте готовы много учиться, много разрабатывать и многое переделывать, и знайте, что это займет много времени.