Кластер для PostgreSQL
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Junior member
- Сообщения: 1
- Зарегистрирован: 09 янв 2007, 02:28
- Откуда: Tyva
Кластер для PostgreSQL
Есть машина 2хXeon, 2Gb памяти, SCSI Raid1 с установленными FreeBSD 6.1 и PostgreSQL 8.0.X. Похоже, железо скоро перестанет справляться с нагрузкой. Заменить сервер на более мощный или добавить процов нельзя, зато есть стопка таких же серверов.
Как ПРАВИЛЬНО сделать кластер на FreeBSD (если нельзя, то в Linux'e) для распределения нагрузки и заставить на нем работать PostgreSQL.
Вопрос к опытным в этом деле людям, потому как google дезориентировал окончательно - прям пазл получается...
Заранее спасибо.
Как ПРАВИЛЬНО сделать кластер на FreeBSD (если нельзя, то в Linux'e) для распределения нагрузки и заставить на нем работать PostgreSQL.
Вопрос к опытным в этом деле людям, потому как google дезориентировал окончательно - прям пазл получается...
Заранее спасибо.
Re: Кластер для PostgreSQL
вам следует определиться, что именно вызывает нагрузку.sherig-orjak-ool писал(а): Похоже, железо скоро перестанет справляться с нагрузкой. Заменить сервер на более мощный или добавить процов нельзя, зато есть стопка таких же серверов.
Очень часто оптимизация нескольких запросов или внимательное изучение настроек 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.
Есть некотрые улучшения в коммерческих поставках PG, но и они, в любом случае, не сделают для вас работу по оптимизации прозрачной для приложения.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.
Цена вопроса по кластеризации и переделке приложения несомненно превысит стоимость покупки самого могучего сервера.
Да самому такое написать можно. Однако он решает только видимую часть айсберга.
Представьте, что один из серверов вышел из строя и пропустил много операций SQL-Update. Потом сервер ввели в эксплуатацию и он начал отвечать на select-ы. Вы же понимаете, что база его не является правильной и содержит весьма и весьма неверные данные.
Вы скажите что а после аварии надо провести консистентность базы, а потом запуск сервера в эксплуатацию? Логично. А что если сервер не отказал, а просто пропустил несколько запросов на UPDATE ибо был перегружен в этот момент? Прокси должен такие проблемные запросы кэшировать? Тогда это весьма нетривиальный прокси получается...
Надо не направлять на такой сервер select-ы, если в кэше есть необработанные update-ы.
Что-то мне кажется, что надежность работы такого прокси является довольно сомнительной.... Я бы не доверил работу СУБД для такой схемы. Угробится...
Представьте, что один из серверов вышел из строя и пропустил много операций SQL-Update. Потом сервер ввели в эксплуатацию и он начал отвечать на select-ы. Вы же понимаете, что база его не является правильной и содержит весьма и весьма неверные данные.
Вы скажите что а после аварии надо провести консистентность базы, а потом запуск сервера в эксплуатацию? Логично. А что если сервер не отказал, а просто пропустил несколько запросов на UPDATE ибо был перегружен в этот момент? Прокси должен такие проблемные запросы кэшировать? Тогда это весьма нетривиальный прокси получается...
Надо не направлять на такой сервер select-ы, если в кэше есть необработанные update-ы.
Что-то мне кажется, что надежность работы такого прокси является довольно сомнительной.... Я бы не доверил работу СУБД для такой схемы. Угробится...
Чтобы не потерялось, добавлю сюда:
http://www.cybertec.at/en/clustercd.html
http://www.cybertec.at/clusterdemo/README_DEMO
Заявляется полная multimaster репликация. Если вчитать README_DEMO, то видно, что реплицируются даже вновь создаваемы пользователи.
Если верить заявленному
Есть два iso с демкой, не качал, не пробовал.
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 с демкой, не качал, не пробовал.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 13 гостей