Наш классический шард PostgreSQL состоит из мастера и двух реплик. Мы мониторим тот факт, что реплик ровно столько, сколько должно быть (зажигаем WARN, если осталась одна, и CRIT, если реплик не осталось). И мониторим отставание реплик, а именно replay_location. Всё это делается парой простых запросов в pg_stat_replication …

more ...

Однажды в результате наложения двух человеческих ошибок при выкатке кода на базы мы сделали DROP SCHEMA data CASCADE; на всех шардах одного из кластеров, в котором лежало около 3 ТБ данных. Это добавило нам много седых волос, позволило проверить свои навыки в PITR прямо в бою и заставило по-другому относиться …

more ...

Пролог

В 9.4 появилась логическая репликация. А потому с 9.4 на 9.5 можно будет обновиться весьма дёшево (по крайней мере так должно быть). Ну а прямо сейчас обновление мажорной версии PostgreSQL — боль. В самом распространённом варианте это выглядит так:

1. Необходимо полностью потушить мастер и дёрнуть pg_upgrade …

more ...

Я расскажу о том, как мы внедрили PostgreSQL в транспорте нотификаций. О том, как менялись требования к хранилищу в ходе развития проекта и как PostgreSQL позволил нам их обеспечить. Терабайты данных, десятки тысяч транзакций в секунду - всё, как мы любим. Разумееется, расскажу о проблемах, с которыми мы столкнулись, и о том, как мы их решили.
more ...

У нас есть сценарии хранения в БД остывающих UGC-данных. Чем старше данные, тем реже за ними приходят. Таблицы с такими данными мы партиционируем по времени и по мере остывания данных перемещаем их с SSD-дисков на SATA. Это даёт очень некислую экономию на стоимости железа. В PostgreSQL есть родной …

more ...