Комментарии 4
Спасибо за статью.
Сколько времени у вас проработала эта связка пгпулов, случались ли нештатные ситуации (вылет ноды из пула, отвал по простой проверке), если да, то как часто. И главный вопрос, какова нагрузка (кол-во запросов в сутки будет достаточно)?
У меня был не очень хороший опыт с пгпулом, и меня мягко говоря он разочаровал, поэтому интересно как у других.
Сколько времени у вас проработала эта связка пгпулов, случались ли нештатные ситуации (вылет ноды из пула, отвал по простой проверке), если да, то как часто. И главный вопрос, какова нагрузка (кол-во запросов в сутки будет достаточно)?
У меня был не очень хороший опыт с пгпулом, и меня мягко говоря он разочаровал, поэтому интересно как у других.
В настоящий момент я сам всё еще наблюдаю за работой этой связки — она пока не в продакшене.
Дата на скриншотах — реальная дата настройки, прошло 10 дней всего.
Сутки мучал pbench'ем — ничего не отвалилось… НО! После теста уже без нагрузки pgpool не смог достучаться до живого primary backend'a и переключился на secondary — если это его обычное поведение, то, однозначно нужно искать другое решение, продолжаю наблюдать пока…
TPS при TPC-B ~650 показывал, голый select ~4500 (scaling factor 5, ключи запуска -j8 -c64) — это при дефолтовой конфигурации postgresql и выключенном synchronous_commit. Показатель, IMHO, весьма скромный, но pgpool тут не при чем, прямое тестирование мастера показывает ~590 по TPC-B, незначительный прирост я так понимаю дает чтение со slave'а.
Дата на скриншотах — реальная дата настройки, прошло 10 дней всего.
Сутки мучал pbench'ем — ничего не отвалилось… НО! После теста уже без нагрузки pgpool не смог достучаться до живого primary backend'a и переключился на secondary — если это его обычное поведение, то, однозначно нужно искать другое решение, продолжаю наблюдать пока…
TPS при TPC-B ~650 показывал, голый select ~4500 (scaling factor 5, ключи запуска -j8 -c64) — это при дефолтовой конфигурации postgresql и выключенном synchronous_commit. Показатель, IMHO, весьма скромный, но pgpool тут не при чем, прямое тестирование мастера показывает ~590 по TPC-B, незначительный прирост я так понимаю дает чтение со slave'а.
Большое спасибо за руководство!
Полностью повторил вашу конфигурацию, но на обычных серверах, а не в среде AWS.
При падении мастера (нода 0), в скрипт failover не передаются параметры нового мастера (нода 1):
При падении же слейва, все работает как ожидается:
Не сталкивались с подобным? Буду признателен за любую подсказку! Такое чувство, что pgpool не видит новую мастер-ноду, хотя она успешно работает в standby-режиме до падения мастера.
Полностью повторил вашу конфигурацию, но на обычных серверах, а не в среде AWS.
При падении мастера (нода 0), в скрипт failover не передаются параметры нового мастера (нода 1):
$ grep 'failover' /var/log/messages
failover_handler: no valid DB node found
execute command: /var/lib/postgresql/9.4/main/failover.sh 0 0
failover: set new primary node: -1При падении же слейва, все работает как ожидается:
$ grep 'failover' /var/log/messages
execute command: /var/lib/postgresql/9.4/main/failover.sh 1 0 db1.example.com /var/lib/postgresql/9.4/main
failover: set new primary node: 0
failover: set new master node: 0Не сталкивались с подобным? Буду признателен за любую подсказку! Такое чувство, что pgpool не видит новую мастер-ноду, хотя она успешно работает в standby-режиме до падения мастера.
$ grep 'failover.sh' /etc/pgpool2/pgpool.conf
failover_command = '/var/lib/postgresql/9.4/main/failover.sh %d %P %H %R'
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка pgpool-II + PostgreSQL + Streaming replication + Hot standby в среде AWS