Но в целом, похожий инструментарий мало когда нужен в production. Объясню почему:
Как правило, если мы говорим про k8s, то вполне хватает обычного pg_dump и cronjob . В случае падения джоба есть prometheus со своим алертингом. Мы, например у себя, сделали отдельный k8s оператор jobchain, который позволяет выполнять цепочку джобов. Собственно, сначала в цепочке выполняются дампы (баз несколько и очередность тоже имеет значение). Потом rclone закидываем в s3. У всего есть статусы k8s и метрики prometheus.
Дампы, как таковые в реальном production, больше нужны для анализа разработке. Для отказоустойчивости/восстановления/отката гораздо лучше подходит штатная репликация ("в обертке" от zalando и т.п.) + wal-g в s3.
Иногда размер БД становится непомерно большим. Сотни ГБ или даже несколько ТБ. И с такими размерами "бэкапить" уже не реально. Ежедневный дамп "начинает наступать на пятки следующему через сутки". Восстанавливать в случае аварии такую БД - это даунтайм больше чем на сутки. В общем "такое себе".
Сидеть и любоваться UI дело конечно приятное, но обычно приходится заниматься другой работой, и лишь только в случае алертинга, начинаешь смотреть "что там, да как". Там уже логи контейнера/pgsql/pg_dump или статусы/события k8s больше расскажут, чем gui.
как правило, на баше пишутся какие-то одноразовые скрипты. Когда нужно "здесь и сейчас, по быстрому". И ничего нет страшного в нагромождении пайпов. Быстро вспомнить все навороты awk бывает некогда.
А когда скрипт начинает быть похожем на программу, то лучше взять нормальный язык программирования и решить задачу на нем.
Ну и заголовок не совсем корректный. awk такая же "команда" в bash. В кавычках - потому, что это никакая не команда, как sed, grep и т.д. Это все утилиты/бинари шела (bash, sh, ashи т. п.)
«наш ДБА, вывел реплику из-под нагрузки, прибил долгоживущие процессы и выполнил стандартную процедуру оптимизации таблиц».
Мне одному кажется, что истории из серии прибить долгие запросы в БД и сделать оптимизацию — должно быть делом рук службы мониторинга/дежурных админов и/или вообще какой-то автоматизации?
А роль ДБА — предотвращать в т.ч. ситуации с долгими запросами.
Красивый инструмент. Респект за старания.
Но в целом, похожий инструментарий мало когда нужен в production. Объясню почему:
Как правило, если мы говорим про k8s, то вполне хватает обычного pg_dump и cronjob . В случае падения джоба есть prometheus со своим алертингом. Мы, например у себя, сделали отдельный k8s оператор jobchain, который позволяет выполнять цепочку джобов. Собственно, сначала в цепочке выполняются дампы (баз несколько и очередность тоже имеет значение). Потом rclone закидываем в s3. У всего есть статусы k8s и метрики prometheus.
Дампы, как таковые в реальном production, больше нужны для анализа разработке. Для отказоустойчивости/восстановления/отката гораздо лучше подходит штатная репликация ("в обертке" от zalando и т.п.) + wal-g в s3.
Иногда размер БД становится непомерно большим. Сотни ГБ или даже несколько ТБ. И с такими размерами "бэкапить" уже не реально. Ежедневный дамп "начинает наступать на пятки следующему через сутки". Восстанавливать в случае аварии такую БД - это даунтайм больше чем на сутки. В общем "такое себе".
Сидеть и любоваться UI дело конечно приятное, но обычно приходится заниматься другой работой, и лишь только в случае алертинга, начинаешь смотреть "что там, да как". Там уже логи контейнера/pgsql/pg_dump или статусы/события k8s больше расскажут, чем gui.
Всё вышесказанное, разумеется - IMHO.
Одна из лучших лекций про "контейнеры"
https://youtu.be/rJRLZfk3a8U?si=kVy8jQIVCdJ9ev_R
А поддержки influxdb, судя по описанию - нет.
как правило, на баше пишутся какие-то одноразовые скрипты. Когда нужно "здесь и сейчас, по быстрому". И ничего нет страшного в нагромождении пайпов. Быстро вспомнить все навороты awk бывает некогда.
А когда скрипт начинает быть похожем на программу, то лучше взять нормальный язык программирования и решить задачу на нем.
Ну и заголовок не совсем корректный. awk такая же "команда" в bash. В кавычках - потому, что это никакая не команда, как sed, grep и т.д. Это все утилиты/бинари шела (bash, sh, ashи т. п.)
Опечатка в заголовке. Наверное имеется ввиду работа с дисками в CentOS? ;)
12 кб????
$ cat > main.go << EOF
package main
func main() { print("hello world") }
EOF
$ go build -o app main.go
$ stat app
Файл: app
Размер: 1519128 Блоков: 2968 Блок В/В: 4096 обычный файл
нам dex как-то больше зашел. Один бинарь на go, без тяжеловесной java.
Можно вообще поднять свой почтовик.
Если кому интересно, сделал тулзу для экспорта данных из nightscout в libreview ( для отчета в медучреждение ).
https://github.com/blutz1982/go-nsexporter-libreview
на Golang.
Мне одному кажется, что истории из серии прибить долгие запросы в БД и сделать оптимизацию — должно быть делом рук службы мониторинга/дежурных админов и/или вообще какой-то автоматизации?
А роль ДБА — предотвращать в т.ч. ситуации с долгими запросами.