Рубрика «pgbouncer»
Работа с базой данных для джунов и вайбкодеров. Соединения
2025-05-11 в 15:20, admin, рубрики: hikaricp, hikaripool, pgbouncer, баги, базы данных, коннект к бд, коннекты, пул соединенийОтказоустойчивый кластер PostgreSQL + Patroni. Опыт внедрения
2019-06-25 в 6:45, admin, рубрики: AWS RDS, consul, devops, miro, patroni, pgbouncer, postgres, postgresql, realtimeboard, redis, Блог компании Miro, Сonsul-templateВ статье я расскажу, как мы подошли к вопросу отказоустойчивости PostgreSQL, почему это стало для нас важно и что в итоге получилось.
У нас высоконагруженный сервис: 2,5 млн пользователей по всему миру, 50К+ активных пользователей каждый день. Сервера находятся в Amazone в одном регионе Ирландии: в работе постоянно 100+ различных серверов, из них почти 50 — с базами данных.
Весь backend — большое монолитное stateful-приложение на Java, которое держит постоянное websocket соединение с клиентом. При одновременной работе нескольких пользователей на одной доске все они видят изменения в режиме реального времени, потому что каждое изменение мы записываем в базу. У нас примерно 10К запросов в секунду к нашим базам. В пиковой нагрузке в Redis мы пишем по 80-100К запросов в секунду.
Читать полностью »
USE, RED, PgBouncer, его настройки и мониторинг
2018-09-11 в 13:12, admin, рубрики: okmeter, pgbouncer, postgres, postgresql, Администрирование баз данных, Блог компании okmeter.io, Серверная оптимизация, Серверное администрирование
Мы начали обновлять в нашем сервисе мониторинг для PgBouncer и решили все немного причесать. Чтобы сделать всё годно, мы притянули самые известные методологии перформанс мониторинга: USE (Utilization, Saturation, Errors) Брендана Грегга и RED (Requests, Errors, Durations) от Тома Уилки.
Далее вы узнаете, как мы всё там навертели и про особенности конфигурационных параметров PgBouncer.
Версионирование и деплой кода PostgreSQL
2017-11-23 в 10:57, admin, рубрики: deploy, pgbouncer, php, plpgsql, postgresql, Блог компании Avito, высокая производительностьСотни баз данных и тысячи хранимых процедур. Как это всё писать, тестировать и деплоить на множество серверов с возможностью быстрого отката в условиях хайлоад 24х7 и не умереть? Интересно? Добро пожаловать под кат!
КЛАСТЕР высокой доступности на postgresql 9.6 + repmgr + pgbouncer + haproxy + keepalived + контроль через telegram
2016-11-01 в 5:33, admin, рубрики: cluster, failover, HA, haproxy, keepalived, pgbouncer, postgresq, replication, repmgr, Администрирование баз данных, Блог компании Этажи, Серверное администрирование, хранение данных, метки: postgresq
На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных. Для ее реализации необходимо определиться со сценариями файловера — это залог успешной работы кластера, протестировать его работу. В двух словах — настраивается репликация, чаще всего асинхронная, и в случае отказа текущего мастера, другая нода(standby) становится текущем «мастером», другие ноды standby начинают следовать за новым мастером.
На сегодняшний день repmgr поддерживает сценарий автоматического Failover — autofailover, что позволяет поддерживать кластер в рабочем состоянии после выхода из строя ноды-мастера без мгновенного вмешательства сотрудника, что немаловажно, так как не происходит большого падения UPTIME. Для уведомлений используем telegram.
Появилась необходимость в связи с развитием внутренних сервисов реализовать систему хранения БД на Postgresql + репликация + балансировка + failover(отказоустойчивость). Как всегда в интернете вроде бы что то и есть, но всё оно устаревшее или на практике не реализуемое в том виде, в котором оно представлено. Было решено представить данное решение, чтобы в будущем у специалистов, решивших реализовать подобную схему было представление как это делается, и чтобы новичкам было легко это реализовать следуя данной инструкции. Постарались описать все как можно подробней, вникнуть во все нюансы и особенности.
Читать полностью »