Comments 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 постгресу.
UFO just landed and posted this here
Нет, но 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, без @ он ругается:(
Sign up to leave a comment.
Отказоустойчивый кластер Master-Slave на PostgreSQL