Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
Господа, что вы посоветуете для кластеринга на PostgreSQL? Интересует системы которые использовались в реальных системах, можно и платные. Главное чтобы было надёжное. Пытались использовать PgPool но это не совсем кластеринг. Он не пишет данные в обе базы, при их обновлении из хранимых процедур, и вообще он вроде работает только как прослойка между клиентом и сервером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2007, 10:49 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
slony I + pgPool II(для балансировки). Это не кластер а просто гибкая репликация, зато надежная и вообще можно организовать failover ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 12:40 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
golden13Господа, что вы посоветуете для кластеринга на PostgreSQL? Интересует системы которые использовались в реальных системах, можно и платные. Главное чтобы было надёжное. Пытались использовать PgPool но это не совсем кластеринг. Он не пишет данные в обе базы, при их обновлении из хранимых процедур, и вообще он вроде работает только как прослойка между клиентом и сервером. не знаю как насчет процедур, но я тестировал так: два pgsql сервера, третья машина для PgPool II, вставлял много данных в базы через PgPool ( обе базы), делал выборки - все ок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 13:03 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
Winnipuh не знаю как насчет процедур, но я тестировал так: два pgsql сервера, третья машина для PgPool II, вставлял много данных в базы через PgPool ( обе базы), делал выборки - все ок. Вставка с клиента нормально происходит. Вставка с хранимой процедуры , происходит только на мастер сервере , так как это видимо происходит в обход pgpool Насчёт Slony. Почитал документацию... пишут что использование Слоника, исключает использование тригеров на таблицах, так как Слоник ставит на каждую свой тригер. Так ли это? Или есть какие обходные пути? В принципе в проекте пока тригеры не используются, но в дальнейшем планируются, поэтому хочется знать заранее чем это грозит :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 14:28 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
golden13 Winnipuh не знаю как насчет процедур, но я тестировал так: два pgsql сервера, третья машина для PgPool II, вставлял много данных в базы через PgPool ( обе базы), делал выборки - все ок. Вставка с клиента нормально происходит. Вставка с хранимой процедуры , происходит только на мастер сервере , так как это видимо происходит в обход pgpool Насчёт Slony. Почитал документацию... пишут что использование Слоника, исключает использование тригеров на таблицах, так как Слоник ставит на каждую свой тригер. Так ли это? Или есть какие обходные пути? В принципе в проекте пока тригеры не используются, но в дальнейшем планируются, поэтому хочется знать заранее чем это грозит :) вообще-то странно, все обращения должны идти через PgPool II, а он уже распределяет запросы: изменение данных - на оба сервера, запрос на выборку из одного. Надо проверить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 15:25 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
golden13 Насчёт Slony. Почитал документацию... пишут что использование Слоника, исключает использование тригеров на таблицах, так как Слоник ставит на каждую свой тригер. Так ли это? Или есть какие обходные пути? В принципе в проекте пока тригеры не используются, но в дальнейшем планируются, поэтому хочется знать заранее чем это грозит :) SLONY "удаляет" триггера только на slave базе(ах). На мастере всё остается на месте. Но даже при этом, триггера на slave можно вернуть на место (только смысл?). Вот только SLONY для кластеринга как-то не очень подходит имхо (ну разве что количество DML операций минимально и идут в основном селекты). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 15:39 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
Winnipuh вообще-то странно, все обращения должны идти через PgPool II, а он уже распределяет запросы: изменение данных - на оба сервера, запрос на выборку из одного. Надо проверить... select my_proc(1); PgPool отправит этот запрос только на одну базу, потому что select. В то время как при выполнении функции my_proc() может быть изменена как структура базы, так и данные. Естественно, PgPool это отследить не может, т.к. запрос уже отправлен в базу. А если в базе не делать хранимок и триггеров, проще и быстрее будет sqlite. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2007, 20:04 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
Thamerlan Вот только SLONY для кластеринга как-то не очень подходит имхо (ну разве что количество DML операций минимально и идут в основном селекты). Тогда вопрос, какие ещё системы кроме Слоника можно (и нужно :) ) использовать для репликации? Повторяю, интересует прежде всего надёжность, ну... и скорость в принципе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 17:16 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
av1985PgCluster? pgCluster старая система и давно не поддерживается, поэтому не хотелось бы её пользовать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 17:17 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
golden13 Тогда вопрос, какие ещё системы кроме Слоника можно (и нужно :) ) использовать для репликации? Повторяю, интересует прежде всего надёжность, ну... и скорость в принципе. Если вам не критична синхронность двух нод (отставание на 3-20 секунд), то тогда SLONY вполне приемлемый выбор. Лично я использую SLONY для подключение репортов к slave node, чтобы максимально разгрузить OLTP master. Про надежность. Что конкретно интересует? Каких-то явных проблем описать не могу. По поводу скорости ... Скорость понятие растяжимое :) Если канал между двумя нодами стабилен, то тогда проблем не должно быть. Если вдруг репликация завалится (допустим не по виде слонов) и в мастере прошло много изменений, то потом процесс "догонки" может быть довольно долгим. У меня сейчас есть 90Гб база со слонами на одном raid5 с ~10-20 конкурентными пользователями. Пока что вроде без проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 17:37 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
Позволю себе повторить и расширить мелькнувший выше вопрос - встречал ли кто решения по репликации постгреса, поддерживающие синхронизацию базы с сотнями схем и хранимых процедур, тысячами таблиц и триггеров? Пока что ничего подобного не видел, хотя сам интересуюсь. На уровне приложения да, подобные вещи реализуются, но такой путь не привлекает. Интересно было бы доработать PgPool так, чтобы он понимал сценарии, распределяя запросы по базам в зависимости от бизнес-логики. Например, вызов хранимой процедуры может изменить состояние базы, но это изменение может коснуться лишь одной схемы, тогда все последующие запросы к этой схеме нужно направлять к соответствующей базе, а на другие базы реплицировать не надо (пример - пользователь указал параметры отчетов, эти параметры сохранены в схеме пользователя в базе, вызвана хранимка для генерации десятка таблиц и видов с нужными данными и далее пользователь просматривает и анализирует содержимое созданных таблиц, а после изменения параметров соответствующие таблицы и виды будут пересозданы, соответственно, при достаточно реплицировать параметры пользователя по всем базам, а пересоздать объекты можно на уровне приложения, прозрачно для пользователя). А вот запросы на обработку основного хранилища данных (в т.ч. с помощью хранимок) необходимо выполнять на всех базах. В принципе, при преобладании чтения над изменением данных, можно просто отправлять все поступающие запросы на все базы, а читать с любой из них, получится зеркальный рэйд. Только при сбое одной из баз сложно будет ее снова в работу запустить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 19:31 |
|
||
|
Кластеринг
|
|||
|---|---|---|---|
|
#18+
golden13 av1985PgCluster? pgCluster старая система и давно не поддерживается, поэтому не хотелось бы её пользовать Это неверно. http://www.pgcluster.org/ Но и верно :-) Они не успевают. К сожалению, даже это малое отставание для нас ставит на нем крест. Почему PGCluster не становится частью проекта PostgreSQL, не понятно. Разногласия ? Отсутствие хорошей репликации очень вредит проекту. Все эти кустарные реализации не внушают доверия. вывод ? сам PostgreSQL не воспринимается всеръез. Хотя причем доверие ? Вопрос-то прост: Как вернуть после сбоя нод в строй без остановки системы ? База 10Gb, активных изменяющих юзеров около 100-200 одновременно. P.S. Видать купит начальство пару MS-в..., все будут довольны. и работать будет. а если слишком дорого окажется, то я уже ищу новую работу, потому как проект будет закрыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2007, 01:04 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34972678&tid=2004825]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 226ms |
| total: | 418ms |

| 0 / 0 |
