Кластер для PostgreSQL

[sherig-orjak-ool]

Есть машина 2хXeon, 2Gb памяти, SCSI Raid1 с установленными FreeBSD 6.1 и PostgreSQL 8.0.X. Похоже, железо скоро перестанет справляться с нагрузкой. Заменить сервер на более мощный или добавить процов нельзя, зато есть стопка таких же серверов.
Как ПРАВИЛЬНО сделать кластер на FreeBSD (если нельзя, то в Linux'e) для распределения нагрузки и заставить на нем работать PostgreSQL.
Вопрос к  опытным в этом деле людям, потому как google дезориентировал окончательно - прям пазл получается...

Заранее спасибо.

[art]

Похоже, железо скоро перестанет справляться с нагрузкой. Заменить сервер на более мощный или добавить процов нельзя, зато есть стопка таких же серверов.

вам следует определиться, что именно вызывает нагрузку.
Очень часто оптимизация нескольких запросов или внимательное изучение настроек postgresql.conf помогают поднять производительность в разы.

Иногда вопрос о кластеризации снимается после vacuum full analyze -)

Кластеризация в PG, как таковом недоступна ни в одном из своих классических видов:
- параллельное исполнение запроса
- разделение запросов на обновление и запись между несколькими репликами.
http://www.postgresql.org/docs/8.2/inte ... ility.html

PostgreSQL does not offer this type of replication, though PostgreSQL two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.

Однако кое что имеется:

Multi-Server Parallel Query Execution

Many of the above solutions allow multiple servers to handle multiple queries, but none allow a single query to use multiple servers to complete faster. This solution allows multiple servers to work concurrently on a single query. This is usually accomplished by splitting the data among servers and having each server execute its part of the query and return results to a central server where they are combined and returned to the user. Pgpool-II has this capability.

Есть некотрые улучшения в коммерческих поставках PG, но и они, в любом случае, не сделают для вас работу по оптимизации прозрачной для приложения.

Цена вопроса по кластеризации и переделке приложения несомненно превысит стоимость покупки самого могучего сервера.

[edo]

может я что-то путаю, но по-моему был тупой балансирующий прокси, который запросы на чтения балансировал между несколькими серверами, а запросы, связанные с модификацией данных слал на все сервера.

[and3008]

Да самому такое написать можно. Однако он решает только видимую часть айсберга.

Представьте, что один из серверов вышел из строя и пропустил много  операций SQL-Update. Потом сервер ввели в эксплуатацию и он начал отвечать на select-ы. Вы же понимаете, что база его не является правильной и содержит весьма и весьма неверные данные.

Вы скажите что а после аварии надо провести консистентность базы, а потом запуск сервера в эксплуатацию? Логично. А что если сервер не отказал, а просто пропустил несколько запросов на UPDATE ибо был перегружен в этот момент? Прокси должен такие проблемные запросы кэшировать? Тогда это весьма нетривиальный прокси получается...
Надо не направлять на такой сервер select-ы, если в кэше есть необработанные update-ы.

Что-то мне кажется, что надежность работы такого прокси является довольно сомнительной.... Я бы не доверил работу СУБД для такой схемы. Угробится...

[art]

Чтобы не потерялось, добавлю сюда:
http://www.cybertec.at/en/clustercd.html
http://www.cybertec.at/clusterdemo/README_DEMO

Заявляется полная multimaster репликация. Если вчитать README_DEMO, то видно, что реплицируются даже вновь создаваемы пользователи.

Если верить заявленному

• multimaster replication
  full support for 2 Phase Commit
  enhanced monitoring (through monitoring server)
  database consistency checker
  out of the box setup
  1 CD per machine
  no additional config necessary
  full support (24 x 7)
  Debian based package management

то получается весьма круто за очень умеренные деньги.



Есть два iso с демкой, не качал, не пробовал.

[apelsin]

multimaster replication
full support for 2 Phase Commit <---- 2PC!

такое обычно работает  медленне чем  просто один дб сервер; т.е. это только для HA.

[art]

такое обычно работает  медленне чем  просто один дб сервер; т.е. это только для HA.

конечно же медленнее, но если запросов на обновление мало, это решение очень привлекательно.