Комментарии 18
Скорость работы этой «прослойки» измеряли?
Я делал все то же самое, потом замерил скорость с pgpool и без него.
Получилось что в среднем pgpool ЗАМЕДЛЯЕТ скорость примерно в 3 раза.
В связке pgbouncer-pgpool-postgres проигрыш (!!!) в сравнении с чистым postgres у меня получился 20-30 процентов.
Самая быстрая комбинация — pgbouncer+postgres
На ней я и остановился. У меня pgpool следит за failover-ами и осуществляет репликацию. При failover помимо «дергания» триггера новому мастеру еще назначается выделенный дополнительный IP (у бывшего мастера этот IP удаляется). Все запросы обрабатывает pgbouncer и переадресовывает эти запросы по этому самому выделенному IP.
Я делал все то же самое, потом замерил скорость с pgpool и без него.
Получилось что в среднем pgpool ЗАМЕДЛЯЕТ скорость примерно в 3 раза.
В связке pgbouncer-pgpool-postgres проигрыш (!!!) в сравнении с чистым postgres у меня получился 20-30 процентов.
Самая быстрая комбинация — pgbouncer+postgres
На ней я и остановился. У меня pgpool следит за failover-ами и осуществляет репликацию. При failover помимо «дергания» триггера новому мастеру еще назначается выделенный дополнительный IP (у бывшего мастера этот IP удаляется). Все запросы обрабатывает pgbouncer и переадресовывает эти запросы по этому самому выделенному IP.
> У меня pgpool следит за failover-ами и осуществляет репликацию.
Вот поэтому «pgpool ЗАМЕДЛЯЕТ скорость примерно в 3 раза.» У pgpool синхронная репликация, из-за этого и тормоза.
Вот поэтому «pgpool ЗАМЕДЛЯЕТ скорость примерно в 3 раза.» У pgpool синхронная репликация, из-за этого и тормоза.
Моя задача была в исследовании принципа построения такого кластера, а не проверка скорости работы pgpool.
А как вы скорость меряли, кстати?
У нас примерно такая же схема, только репликация нативная и синхронная. Pgbouncer при каком-то пороге нагрузки начал не работать, а скорее тупить. У pgpool2 можно включить все кэши и будет все быстро.
У нас примерно такая же схема, только репликация нативная и синхронная. Pgbouncer при каком-то пороге нагрузки начал не работать, а скорее тупить. У pgpool2 можно включить все кэши и будет все быстро.
Производительность конечно будет проседать, так как при синхронной репликации мы вынужденны ждать отклика от всех узлов кластера, для завершения каждой транзакции. То что проседает в три раза — это думаю еще не предел, но все равно, в качестве бонуса мы получаем гарантированно синхронные копии БД, без отставания по времени. Все равно есть класс задач, где БД по сути хранит состояние некой распределенной системы. В такой ситуации база данных выступает в качестве единой точки отказа. Хотя порой развертывать отказоустойчивый кластер на трех (а с резервированием балансировщика и четырех) серверах — это для многих проектов роскошь. Думаю отказоустойчивый самовостанавливающийся Мастер-Мастер на двух — это более востребованное решение.
У вас вместо одной точки отказа стало две.
Ставьте вместо него два прокси с возможностью на них переключатся с мастера на слейв PostgreSQL и наоборот.
Ставьте вместо него два прокси с возможностью на них переключатся с мастера на слейв PostgreSQL и наоборот.
Я однажды исследовал возможности pgpool, в конфигурацию были включены аж два pgpool сервера с heartbeat для отказоустойчивости. Всё бы хорошо, отказоустойчивость без слабого звена, но меня остановило то, что есть функции, которые нельзя исполнить на двух серверах и получить одинаковый результат (простая now(), к примеру, исполняется всегда только на одном из серверов) ). Такие функции теоретически помещаются в белый список, но это накладывает ограничения на приложения, которые могут работать с сервером. Пришлось остановиться на стандартной постгресовской репликации. Получаем отказоустойчивость без проблем с производительностью, с простой конфигурацией.
Адъ. Имхо пока сами разработчики постгреса не озаботятся тем, чтобы все из коробки ставилось само на несколько машин кластера, само поддерживало failover и онлайн-добавление новых машин в кластер (в том числе инкапсулируя в себе pg_start_backup и rsync), так и будет продолжаться эта вакханалия. И так и будут их продолжать игнорировать всякие амазоны сотоварищи (я имею в виду amazon rds), предпочитая mysql постгресу.
НЛО прилетело и опубликовало эту надпись здесь
Нет, но mysql гораздо более популярен, это перевешивает. Можно «перевешивать» либо популярностью, либо богатством возможностей.
Это все стереотипы для тех, кто застрял на 4 верcии mysql и 7 postgres. Postgres уже давно стал проще, веселее, быстрее и даже появился под венду. И что касается geo, тут ему равных вообще нет. Плюс он дикими темпами развивается. В версии 9.3 они столько всего сделали, что уже очень хочется его в бой.
А mysql мы уже отовсюду почти выпилили — какой-то он непредсказуемый порой.
А mysql мы уже отовсюду почти выпилили — какой-то он непредсказуемый порой.
К мускулю в коробке поставляется двести китайцев кодеров и один плющевый фрик чтобы все допилить под ваши нужды. По цене выходит раза в три дороже чем ДБ2 и во столько же раз тормознее, зато запускается на всем у чего есть процессор и оперативная память. В общем кому то нравится.
Percona mysql, по крайней мере, умеет приличную master-master репликацию из коробки.
Т.е. вы можете перемещать IP адрес между нодами как вам удобно — они идентичны и реплицируются в две (три ) стороны.
А для добавления нового сервера — да, там тоже нужно восстановить его с мастера.
Т.е. вы можете перемещать IP адрес между нодами как вам удобно — они идентичны и реплицируются в две (три ) стороны.
А для добавления нового сервера — да, там тоже нужно восстановить его с мастера.
Вот эту строчку подредактируйте пожалуйста: ssh -T postgres$NEW_MASTER touch $TRIGGER_FILE, вместо неё надо ssh -T postgres@$NEW_MASTER touch $TRIGGER_FILE, без @ он ругается:(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отказоустойчивый кластер Master-Slave на PostgreSQL