Vitaliy Kukharik @Vitaly2606
Founder & CTO at autobase.tech
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Chief Technology Officer (CTO), Database Administrator
UPD: проект postgresql_cluster переименован в autobase. Теперь продукт называется Autobase for PostgreSQL®.
Не надо ничего бояться, надо жить и улыбаться :)
Мы разместили проект на Product Hunt: https://www.producthunt.com/posts/postgresql-cluster-org
Буду благодарен за вашу поддержку!
Этот отзыв действительно от пользователя, который работает с нашим продуктом, я не просил его оставлять.
Спасибо за отзыв! Рад, что инструментарий полезен для Вас.
Была когда то мысль тоже большую базу (более 30TB) запихнуть в ZFS для сжатия, но решил попробовать timescaledb расширение задействовать его компрессию (детали https://www.timescale.com/blog/time-series-compression-algorithms-explained/), поскольку данные time siries это оказалось подходящее решение. В результате пожал данные более чем в 10 раз (пример https://twitter.com/vkukharik/status/1396827117976002560?s=61&t=-fTOgLwm9frBPcq560_sEA) и примерно во столько же уменьшилось время выполнения аналитических запросов (пример https://twitter.com/vkukharik/status/1397552808514179073?s=61&t=U-YnfyEoacmBtZ1qkWjOPQ) поскольку меньше сидели в disk I/O в пользу CPU (запаса ресурсов cpu было достаточно).
Отличная статья, спасибо!
Чуть более года назад тоже разбирались с проблемой связанной с подтранзакциями в нагруженной системе. Я тестировал патч v17 - https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/22
В результате была написана статья, рекомендую почитать https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful
Смотрю уже доступен патч v24, надо будет выделить время и проверить что изменилось. А пока, пришли к выводу что надо выпиливать использование подтранзакций в нагруженных системах.
Наливайте ваши реплики из бэкапа, пример pgbackrest, или wal_g, или pg_probackup). Таким образом Вы избавляете узлы текущего кластера от дополнительной нагрузки вызванной копированием данных с помощью basebackup. Параметр create_replica_methods - https://patroni.readthedocs.io/en/latest/replica_bootstrap.html#building-replicas
У меня обычно это сводится к одной команде:
ansible-playbook add_pgnode.yml
Желательно выносить ETCD кластер на отдельные сервера. Это даст несколько преимуществ:
Упрощение администрирования. Например, перезапуск сервера без влияния на работу кластера etcd
Возможность использовать один кластер etcd для нескольких кластеров Patroni
Снижение рисков ухудшения стабильности кластера etcd, вызванного скачками нагрузки на базу данных.
@Kilorбольшое Вам спасибо!
Я давно мечтаю о подобном инструменте для мониторинга и детального анализа Query Plans.
у проекта pgwatch2 свое видение дашбордов, у меня другое. Переделывал лично для себя, и уже несколько лет развивается параллельно, по части метрик и дашбордов, сам код сборщика не менял.
Либо просто запустить
pgwatch2 Postgres.ai Edition
- https://gitlab.com/postgres-ai/pgwatch2 который уже содержит множество "полезных SQL-запросов" и получить графики состояния базы данных (в Grafana) за неделю, месяц, и год (при необходимости).Demo: https://pgwatch.postgres.ai
demo/demo
вот мастер-класс от авторов проекта (в том числе о алгоритме работы Patroni) - https://pgconf.ru/2018/108567
а вот автоматизация деплая таких кластеров - https://github.com/vitabaks/postgresql_cluster
Логическое декодирование применимо при не больших нагрузках. Когда мы говорим о 2 и более WAL в секунду то уже могут быть проблемы с лагом репликации.
https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/32
К слову PostgresPro автоматизировать развертывание кластеров тоже умеем - https://github.com/vitabaks/postgresql_cluster/issues/38
В продолжение разговора о lock_timeout и retries - https://postgres.ai/blog/20210923-zero-downtime-postgres-schema-migrations-lock-timeout-and-retries
pgbackrest.org/user-guide.html#restore/option-db-include
Для нагруженной, и тем более боевой среды, не стоит размещать данные etcd на тех же дисках что и база данных (как и любые другие сервисы интенсивно использующие ресурсы дисковой подсистемы).
Сам же etcd кластер, если он выделен только под кластер patroni, не требует ssd, и может стабильно работать и на обычных дисках, так как нагрузка от Patroni на etcd совсем не большая.
Если в Вашей инфраструктуре множество (сотни и тысячи) кластеров Patroni, и вы используете общий — выделенный кластер etcd, тогда желательно использовать ssd диски, а так же выделить уже больше ядер CPU и оперативной памяти.
Ну это ведь спорный вопрос. Нельзя сказать, что всем нужна именно VictoriaMetrics, так как каждый выбирает систему из своих каких-либо личных соображений, что больше всего подходит под его задачи, что он понимает.
Для этого критерия я бы выбрал PostgreSQL с расширением timescaledb. Во первых — потому что я специализируюсь по СУБД PostgreSQL, во вторых — это действительно SQL, в третьих — мне вполне достаточно того уровня сжатия который может предоставить timescaledb для секций.