Прочитал на stackoverflow ответ от DBA Postgresql на тему размещения субд в контейнерах. Ответу уже 3 года, но с тех пор принципиально ничего не изменилось. Кратко смысл такой:
▪ Вам надо монтировать директорию с БД к хосту. Докеровская файловая система вообще не пригодна для интенсивной записи.
▪ Вам надо использовать сеть хостовой системы, чтобы не было снижения производительности на накладные расходы.
Эти 2 условия практически полностью нивелируют удобства Docker. Большого смысла запускать СУБД в контейнере нет. Речь идёт о нагруженной базе данных в проде.
Есть большой опыт использования небольших баз данных и кластеров postgresql в kubernetes у компании Zalando. Я делал отдельную заметку по их выступлению с этой темой на конференции. Там идея такая - большие нагруженные базы в контейнерах не запускают. А вот небольшие базы отдельных микросервисов запускают в kubernetes. Это позволяет организовать удобное централизованное управление и деплой новых баз для различных сервисов и команд.
У меня была еще одна заметка на тему базы данных в Docker. Там я делаю выжимку из статьи компании Percona о её собственных тестах производительности БД в контейнерах. Там вывод такой же, как и в у DBA со stackoverflow. Нужно обязательно использовать сеть хоста, чтобы не было просадки производительности.
В итоге получается, что для хорошей производительности, БД жёстко мапится к самому хосту и сетью, и диском. Ни о каком stateless подходе, на который в первую очередь ориентированы контейнеры, речи не идёт. Польза контейнеров в истории с субд может быть только при использовании большого количества ненагруженных баз, управление которыми может быть организовано с помощью средств оркестрации контейнерами.
У меня в практике как то раз был случай, когда база данных Mysql, запущенная в контейнере, просто исчезла. Разработчики запустили один проект заказчику полностью в контейнерах. В какой-то момент замапленная директория с файлами БД оказалась полностью пустой. Был такой древний баг. Его уже давно пофиксили.
Написал заметку, чтобы вы лишний раз подумали, когда будете использовать докер, а нужен ли он тут. Запускать одиночную субд на хосте в контейнере нет никакого смысла. Точно так же ее можно установить через пакетный менеджер и запустить. Работать будет быстрее, проблем будет меньше.
#postgresql #mysql #docker
▪ Вам надо монтировать директорию с БД к хосту. Докеровская файловая система вообще не пригодна для интенсивной записи.
▪ Вам надо использовать сеть хостовой системы, чтобы не было снижения производительности на накладные расходы.
Эти 2 условия практически полностью нивелируют удобства Docker. Большого смысла запускать СУБД в контейнере нет. Речь идёт о нагруженной базе данных в проде.
Есть большой опыт использования небольших баз данных и кластеров postgresql в kubernetes у компании Zalando. Я делал отдельную заметку по их выступлению с этой темой на конференции. Там идея такая - большие нагруженные базы в контейнерах не запускают. А вот небольшие базы отдельных микросервисов запускают в kubernetes. Это позволяет организовать удобное централизованное управление и деплой новых баз для различных сервисов и команд.
У меня была еще одна заметка на тему базы данных в Docker. Там я делаю выжимку из статьи компании Percona о её собственных тестах производительности БД в контейнерах. Там вывод такой же, как и в у DBA со stackoverflow. Нужно обязательно использовать сеть хоста, чтобы не было просадки производительности.
В итоге получается, что для хорошей производительности, БД жёстко мапится к самому хосту и сетью, и диском. Ни о каком stateless подходе, на который в первую очередь ориентированы контейнеры, речи не идёт. Польза контейнеров в истории с субд может быть только при использовании большого количества ненагруженных баз, управление которыми может быть организовано с помощью средств оркестрации контейнерами.
У меня в практике как то раз был случай, когда база данных Mysql, запущенная в контейнере, просто исчезла. Разработчики запустили один проект заказчику полностью в контейнерах. В какой-то момент замапленная директория с файлами БД оказалась полностью пустой. Был такой древний баг. Его уже давно пофиксили.
Написал заметку, чтобы вы лишний раз подумали, когда будете использовать докер, а нужен ли он тут. Запускать одиночную субд на хосте в контейнере нет никакого смысла. Точно так же ее можно установить через пакетный менеджер и запустить. Работать будет быстрее, проблем будет меньше.
#postgresql #mysql #docker
Рекомендую к просмотру интересное выступление с HighLoad ++ Даниила Захлыстова (Яндекс) - Надежные и быстрые бэкапы PostgreSQL. Речь там идёт про всем известный инструмент WAL-G для бэкапов баз PostgreSQL.
Выступление короткое и достаточно ёмкое. Рассказано в основном про нововведения готовящегося релиза на момент записи трансляции, так как в целом про WAL-G много информации. Релиз v1.0 в итоге состоялся 31 мая.
WAL-G один из лучших бесплатный инструмент для резервного копирования PostgreSQL. Поддерживает полные и инкрементные бэкапы. Его отличает хорошая поддержка современных облачных хранилищ для хранения архивов.
В видео помимо непосредственно рассказа о WAL-G дана общая информация по бэкапам баз данных, что может быть интересно для тех, кто не сильно разбирается в этой теме.
📌 Полезные ссылки:
Youtube - https://www.youtube.com/watch?v=DcIq7H622dQ
Тэзисы выступления - https://www.highload.ru/spring/2021/abstracts/7276
Исходники WAL-G - https://github.com/wal-g/wal-g
Статья с настройкой и примерами - https://habr.com/ru/post/486188/
В связи с тем, что сейчас многие переезжают на PostgreSQL, в том числе с 1С, информация актуальна. Стоит сохранить в закладках.
#backup #postgresql
Выступление короткое и достаточно ёмкое. Рассказано в основном про нововведения готовящегося релиза на момент записи трансляции, так как в целом про WAL-G много информации. Релиз v1.0 в итоге состоялся 31 мая.
WAL-G один из лучших бесплатный инструмент для резервного копирования PostgreSQL. Поддерживает полные и инкрементные бэкапы. Его отличает хорошая поддержка современных облачных хранилищ для хранения архивов.
В видео помимо непосредственно рассказа о WAL-G дана общая информация по бэкапам баз данных, что может быть интересно для тех, кто не сильно разбирается в этой теме.
📌 Полезные ссылки:
Youtube - https://www.youtube.com/watch?v=DcIq7H622dQ
Тэзисы выступления - https://www.highload.ru/spring/2021/abstracts/7276
Исходники WAL-G - https://github.com/wal-g/wal-g
Статья с настройкой и примерами - https://habr.com/ru/post/486188/
В связи с тем, что сейчас многие переезжают на PostgreSQL, в том числе с 1С, информация актуальна. Стоит сохранить в закладках.
#backup #postgresql
Если вам вдруг понадобится база данных PostgreSQL для каких-то целей на время, можно воспользоваться готовым сервисом с бесплатным тарифным планом. Например - https://bit.io. Они бесплатно дают PostgreSQL managed database service с ограничением размера базы в 10 Гб и не более 10 миллионов запросов в месяц.
Подобный сервис может быть полезен в первую очередь для каких-то тестов, когда не хочется поднимать и настраивать свою базу данных. В bit.io для регистрации нужен только email. Сразу после регистрации вы получите тестовую базу данных и параметры подключения к ней. Не удаляйте ее. У меня не получилось после удаления заново создать бесплатную базу. То ли глюк, то ли какое-то ограничение, я не понял.
Чтобы узнать параметры подключения к базе, в личном кабинете слева нажмите на кнопку Connect. Увидите адрес сервера, имя базы, пароль от неё. Доступ к базе возможен как через внешнее подключение, так и через веб интерфейс личного кабинета, что упрощает управление. Я сразу же проверил подключение через HeidiSQL. Без проблем подключился.
#бесплатно #postgresql
Подобный сервис может быть полезен в первую очередь для каких-то тестов, когда не хочется поднимать и настраивать свою базу данных. В bit.io для регистрации нужен только email. Сразу после регистрации вы получите тестовую базу данных и параметры подключения к ней. Не удаляйте ее. У меня не получилось после удаления заново создать бесплатную базу. То ли глюк, то ли какое-то ограничение, я не понял.
Чтобы узнать параметры подключения к базе, в личном кабинете слева нажмите на кнопку Connect. Увидите адрес сервера, имя базы, пароль от неё. Доступ к базе возможен как через внешнее подключение, так и через веб интерфейс личного кабинета, что упрощает управление. Я сразу же проверил подключение через HeidiSQL. Без проблем подключился.
#бесплатно #postgresql
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
Решил написать небольшую шпаргалку по работе в консоли с PostgreSQL. Последнее время всё чаще и чаще приходится иметь с ней дело по двум причинам:
1️⃣ Все новые установки Zabbix Server делаю на postgresql.
2️⃣ Намного чаще стали использовать postgresql в связке с 1С.
PostgreSQL создаёт отдельного пользователя Linux postgres, так что все команды буду делать с указанием этого пользователя. Я обычно работаю так, хотя никто не мешает сразу авторизоваться под ним и запускать команды напрямую. Второй момент - в зависимости от дистрибутива и пакета установки, бинарники postgresql могут находиться в разных местах и не всегда переменная path будет применена. Так что может понадобиться полный путь к исполняемому файлу (pg_dump, psql и т.д.).
📌 Просмотр списка баз:
📌 Создание текстового дампа базы данных:
📌 Сжимаем дамп на лету с помощью pigz (умеет жать всеми ядрами):
📌 Восстановление базы данных в новую базу (сначала создаём её):
Для автоматических бэкапов могу порекомендовать бесплатную программу SQLBackupAndFTP.
📌 Выход из консоли psql (часто забываю):
📌 Создать пользователя:
Задать пароль:
📌 Посмотреть список пользователей:
📌 Дать полные права на базу:
📌 Назначить пользователя владельцем базы:
📌 Выполнить очистку (-f) и анализ (-z) базы данных Postgres Pro:
📌 Переиндексировать базу:
📌 Удалить базу данных:
#postgresql #bash
1️⃣ Все новые установки Zabbix Server делаю на postgresql.
2️⃣ Намного чаще стали использовать postgresql в связке с 1С.
PostgreSQL создаёт отдельного пользователя Linux postgres, так что все команды буду делать с указанием этого пользователя. Я обычно работаю так, хотя никто не мешает сразу авторизоваться под ним и запускать команды напрямую. Второй момент - в зависимости от дистрибутива и пакета установки, бинарники postgresql могут находиться в разных местах и не всегда переменная path будет применена. Так что может понадобиться полный путь к исполняемому файлу (pg_dump, psql и т.д.).
📌 Просмотр списка баз:
# sudo -u postgres psql -U postgres -l📌 Создание текстового дампа базы данных:
# sudo -u postgres pg_dump -U postgres basa01 \> ~/basa01.sql📌 Сжимаем дамп на лету с помощью pigz (умеет жать всеми ядрами):
# sudo -u postgres pg_dump -U postgres basa01 \| pigz > ~/basa01.sql.gz📌 Восстановление базы данных в новую базу (сначала создаём её):
# sudo -u postgres createdb -U postgres \-T template0 basa02# sudo -u postgres psql -U postgres basa02 \< ~/basa01.sqlДля автоматических бэкапов могу порекомендовать бесплатную программу SQLBackupAndFTP.
📌 Выход из консоли psql (часто забываю):
$ \q📌 Создать пользователя:
# sudo -u postgres createuser -U postgres zabbixЗадать пароль:
# sudo -u postgres psql -U postgres -c \"ALTER USER zabbix PASSWORD 'secpasswd'"📌 Посмотреть список пользователей:
# sudo -u postgres psql -U postgres -c \"select * from pg_user"📌 Дать полные права на базу:
# sudo -u postgres psql -U postgres -c \"GRANT ALL PRIVILEGES ON DATABASE zabbixdb to zabbix"📌 Назначить пользователя владельцем базы:
# sudo -u postgres psql -U postgres -c \"ALTER DATABASE zabbixdb OWNER TO zabbix"📌 Выполнить очистку (-f) и анализ (-z) базы данных Postgres Pro:
# sudo -u postgres vacuumdb -U postgres -f -z -d basa01📌 Переиндексировать базу:
# sudo -u postgres reindexdb -U postgres -d basa01📌 Удалить базу данных:
# sudo -u postgres psql -U postgres -c \"DROP DATABASE basa01"#postgresql #bash
Вчера в комментариях к заметке про PostgreSQL посоветовали утилиту для бэкапа - pg_probackup. Я не знал про неё и никогда не использовал, но решил посмотреть. Оказалось, это очень удобный и надёжный вариант бэкапа баз данных PostgreSQL. Расскажу про особенности и варианты использования этой утилиты.
Авторами pg_probackup является небезызвестная компания Postgres Professional - российская компания, разработчик систем управления базами данных. Утилита поддерживает как ванильные версии postgres, так и собственные платные сборки postgres pro.
📌Pg_probackup умеет:
▪ Выполнять полные и инкрементные бэкапы как отдельных серверов, так и кластеров.
▪ Делать инкрементные бэкапы разными способами: разностное копирование, страничное копирование или копирование изменений. Разные способы дают разную нагрузку на систему и занимают разное количество времени.
▪ Выполнять контроль целостности данных и проверку резервных копий без восстановления самих данных.
▪ Управлять политиками хранения резервных копий в соответствии с заданными параметрами.
▪ Самостоятельно сжимать данные без внешних архиваторов.
▪ Работать в режиме клиент-сервер, то есть настраивается сервер хранения pg_probackup, который сам подключается к хостам с postgresql и забирает бэкапы.
▪ Отдельно поддерживает возможность бэкапа произвольных директорий и файлов. Например, директорию с конфигурацией кластера, с логами или какими-то самописными скриптами.
▪ Вести каталог резервных копий с метаданными архивов, данные о которых может отдавать в формате json.
Продукт многофункциональный, который закрывает полностью вопрос с бэкапами, политикой хранения и мониторинга. Получая информацию об архивах в json, очень легко прикрутить мониторинг к тому же Zabbix Server или Prometheus.
Как можно понять из описания, pg_probackup - универсальный инструмент, который подойдёт как для полного бэкапа одиночных баз и серверов, так и кластеров в различных режимах инкрементов. Архивы можно хранить локально или передавать по сети в единый каталог.
У утилиты есть подробное описание на русском языке. Для установки созданы репозитории под все популярные системы, в том числе отечественные.
Примеры запуска и использования приводить не буду, так как всё подробно и по-русски описано в документации. В общем случае сначала надо инициализировать каталог резервных копий, потом добавить туда сервер PostgreSQL, настроить политику хранения, запустить бэкап.
❓Напрашивается важный вопрос. А когда стоит переходить к подобным бэкапам от простых дампов. Однозначного ответа тут нет. Ориентироваться нужно по следующим признакам:
1️⃣ Вам нужна возможность откатить состояние базы на любой момент в прошлом. Тогда дампы вообще не подходят.
2️⃣ Размер базы данных такой, что выполнение дампа занимает значительное время и снижает производительность сервера.
3️⃣ Хочется иметь большую глубину хранения резервных копий, но в полных дампах она будет занимать слишком много места.
По моим прикидкам, если сжатый дамп начинает занимать более 5 Гб, стоит думать о других способах создания и хранения резервных копий БД.
Исходники / Документация
#postgresql #backup
Авторами pg_probackup является небезызвестная компания Postgres Professional - российская компания, разработчик систем управления базами данных. Утилита поддерживает как ванильные версии postgres, так и собственные платные сборки postgres pro.
📌Pg_probackup умеет:
▪ Выполнять полные и инкрементные бэкапы как отдельных серверов, так и кластеров.
▪ Делать инкрементные бэкапы разными способами: разностное копирование, страничное копирование или копирование изменений. Разные способы дают разную нагрузку на систему и занимают разное количество времени.
▪ Выполнять контроль целостности данных и проверку резервных копий без восстановления самих данных.
▪ Управлять политиками хранения резервных копий в соответствии с заданными параметрами.
▪ Самостоятельно сжимать данные без внешних архиваторов.
▪ Работать в режиме клиент-сервер, то есть настраивается сервер хранения pg_probackup, который сам подключается к хостам с postgresql и забирает бэкапы.
▪ Отдельно поддерживает возможность бэкапа произвольных директорий и файлов. Например, директорию с конфигурацией кластера, с логами или какими-то самописными скриптами.
▪ Вести каталог резервных копий с метаданными архивов, данные о которых может отдавать в формате json.
Продукт многофункциональный, который закрывает полностью вопрос с бэкапами, политикой хранения и мониторинга. Получая информацию об архивах в json, очень легко прикрутить мониторинг к тому же Zabbix Server или Prometheus.
Как можно понять из описания, pg_probackup - универсальный инструмент, который подойдёт как для полного бэкапа одиночных баз и серверов, так и кластеров в различных режимах инкрементов. Архивы можно хранить локально или передавать по сети в единый каталог.
У утилиты есть подробное описание на русском языке. Для установки созданы репозитории под все популярные системы, в том числе отечественные.
Примеры запуска и использования приводить не буду, так как всё подробно и по-русски описано в документации. В общем случае сначала надо инициализировать каталог резервных копий, потом добавить туда сервер PostgreSQL, настроить политику хранения, запустить бэкап.
❓Напрашивается важный вопрос. А когда стоит переходить к подобным бэкапам от простых дампов. Однозначного ответа тут нет. Ориентироваться нужно по следующим признакам:
1️⃣ Вам нужна возможность откатить состояние базы на любой момент в прошлом. Тогда дампы вообще не подходят.
2️⃣ Размер базы данных такой, что выполнение дампа занимает значительное время и снижает производительность сервера.
3️⃣ Хочется иметь большую глубину хранения резервных копий, но в полных дампах она будет занимать слишком много места.
По моим прикидкам, если сжатый дамп начинает занимать более 5 Гб, стоит думать о других способах создания и хранения резервных копий БД.
Исходники / Документация
#postgresql #backup
Существуют разные подходы к мониторингу. Можно настраивать одну универсальную систему и всё замыкать на неё. Это удобно в том плане, что всё в одном месте. Но мониторинг каждого отдельного элемента будет не самым лучшим.
Другой подход - для каждого продукта использовать тот мониторинг, который заточен именно под него. Например, такой мониторинг есть для Nginx - NGINX Amplify. Или мониторинг для баз данных от Percona - Percona Monitoring and Management (PMM). Про последний я и хочу сегодня рассказать.
Percona Monitoring and Management - open source мониторинг для баз данных MySQL, PostgreSQL и MongoDB. Построен на базе своего PMM Server и PMM Agent. Визуализация метрик реализована через Grafana.
Благодаря тому, что это узкоспециализированный продукт, его очень легко установить и настроить. По сути и настраивать то нечего. Достаточно установить сервер, агенты на хосты с БД и дальше смотреть метрики в готовых дашбордах Графаны.
Это не сравнится с тем, что предлагает Zabbix по мониторингу баз данных. Да, все те же метрики в него тоже можно передать. Но настроить всё это в готовую систему с метриками, триггерами, оповещениями, графиками и дашбордами очень хлопотно. А в PMM всё это работает сразу после установки. Времени нужно минимум, чтобы запустить мониторинг.
В принципе, если для вас важны базы данных, подобные мониторинги можно и отдельно разворачивать рядом с основным, а потом события со всех мониторингов собирать в одном месте. Например, с помощью OnCall.
Как я уже сказал, установить PMM очень просто. Можете сами оценить сложность и трудозатраты - Install Percona Monitoring and Management. Буквально 10 минут копипасты: ставим сервер, ставим клиент, соединяем клиента с сервером, добавляем в базу пользователя для сбора метрик. Если я правильно понял, то PMM построен на базе prometheus и использует метрики с его exporters.
Как всё это выглядит, можете посмотреть в публичном Demo. Там даже аутентификация не нужна. Помимо метрик баз данных PMM может собирать типовые метрики сервера Linux, HAProxy, выполнять внешние проверки tcp портов или забирать метрики по http.
Проект относительно свежий (2019 год) и очень активно развивается.
⇨ Сайт / Установка / Demo / Исходники
#мониторинг #mysql #postgresql
Другой подход - для каждого продукта использовать тот мониторинг, который заточен именно под него. Например, такой мониторинг есть для Nginx - NGINX Amplify. Или мониторинг для баз данных от Percona - Percona Monitoring and Management (PMM). Про последний я и хочу сегодня рассказать.
Percona Monitoring and Management - open source мониторинг для баз данных MySQL, PostgreSQL и MongoDB. Построен на базе своего PMM Server и PMM Agent. Визуализация метрик реализована через Grafana.
Благодаря тому, что это узкоспециализированный продукт, его очень легко установить и настроить. По сути и настраивать то нечего. Достаточно установить сервер, агенты на хосты с БД и дальше смотреть метрики в готовых дашбордах Графаны.
Это не сравнится с тем, что предлагает Zabbix по мониторингу баз данных. Да, все те же метрики в него тоже можно передать. Но настроить всё это в готовую систему с метриками, триггерами, оповещениями, графиками и дашбордами очень хлопотно. А в PMM всё это работает сразу после установки. Времени нужно минимум, чтобы запустить мониторинг.
В принципе, если для вас важны базы данных, подобные мониторинги можно и отдельно разворачивать рядом с основным, а потом события со всех мониторингов собирать в одном месте. Например, с помощью OnCall.
Как я уже сказал, установить PMM очень просто. Можете сами оценить сложность и трудозатраты - Install Percona Monitoring and Management. Буквально 10 минут копипасты: ставим сервер, ставим клиент, соединяем клиента с сервером, добавляем в базу пользователя для сбора метрик. Если я правильно понял, то PMM построен на базе prometheus и использует метрики с его exporters.
Как всё это выглядит, можете посмотреть в публичном Demo. Там даже аутентификация не нужна. Помимо метрик баз данных PMM может собирать типовые метрики сервера Linux, HAProxy, выполнять внешние проверки tcp портов или забирать метрики по http.
Проект относительно свежий (2019 год) и очень активно развивается.
⇨ Сайт / Установка / Demo / Исходники
#мониторинг #mysql #postgresql
Те, кто постоянно работают с Postgresql наверняка знают про такой параметр, как stats_temp_directory. В самой документации по СУБД сказано, что его перенос в ОЗУ снизит нагрузку на файловое хранилище и увеличит быстродействие.
Я в обязательном порядке переносил это хранилище для временных данных статистики в tmpfs, потому что при использовании SSD этот каталог очень быстро съедал его ресурс. И это не пустые опасения, как часто бывает с SSD. Я реально видел по мониторингу, как утекал ресурс. Там идёт постоянная активная перезапись.
Хорошая новость в том, что в Postgres 15 больше не потребуется это делать. Там все подсчёты статистики выполняются в памяти по умолчанию. Такого параметра, как stats_temp_directory больше нет.
Сейчас уже активно обновляют или ставят 1С вместе с Postgres 15, так что информирую. Сборку postgresql для 1С можно скачать тут - https://1c.postgres.ru. 15-я уже в наличии.
#postgresql
Я в обязательном порядке переносил это хранилище для временных данных статистики в tmpfs, потому что при использовании SSD этот каталог очень быстро съедал его ресурс. И это не пустые опасения, как часто бывает с SSD. Я реально видел по мониторингу, как утекал ресурс. Там идёт постоянная активная перезапись.
Хорошая новость в том, что в Postgres 15 больше не потребуется это делать. Там все подсчёты статистики выполняются в памяти по умолчанию. Такого параметра, как stats_temp_directory больше нет.
Сейчас уже активно обновляют или ставят 1С вместе с Postgres 15, так что информирую. Сборку postgresql для 1С можно скачать тут - https://1c.postgres.ru. 15-я уже в наличии.
#postgresql
Я обновил и актуализировал популярную на сайте статью по настройке сервера 1С:
Установка и настройка 1С на Debian с PostgreSQL
⇨ https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/
Статья подробная. Позволяет простым копированием и ставкой настроить указанную связку. В ней показаны:
✅ Установка и настройка свежей версии сервера 1С и PosgtreSQL 15 на Debian 11.
✅ Пример создания баз данных на этом сервере и подключение к ним.
✅ Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации.
✅ Как я тестирую восстановление из sql дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы в консоли Linux. Всё это автоматизируется скриптами.
✅ Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.
Всё описанное основано на личном опыте настройки и эксплуатации подобных систем. Ни у кого ничего не смотрел, лучших практик не знаю. Придумал всё сам и сделал, как посчитал нужным. Так что не нужно это воспринимать как оптимальное решение.
#1с #postgresql
Установка и настройка 1С на Debian с PostgreSQL
⇨ https://serveradmin.ru/ustanovka-i-nastrojka-1s-na-debian-s-postgresql/
Статья подробная. Позволяет простым копированием и ставкой настроить указанную связку. В ней показаны:
✅ Установка и настройка свежей версии сервера 1С и PosgtreSQL 15 на Debian 11.
✅ Пример создания баз данных на этом сервере и подключение к ним.
✅ Бэкап и обслуживание postgresql баз утилитами сервера бд. Рассказываю про свой подход к этому процессу и привожу скрипты автоматизации.
✅ Как я тестирую восстановление из sql дампов и делаю контрольную проверку в виде выгрузки баз в .dt файлы в консоли Linux. Всё это автоматизируется скриптами.
✅ Рассказываю про свои подходы к мониторингу этих бэкапов и выгрузок, чтобы всегда быть уверенным в том, что у тебя есть гарантированно рабочие бэкапы.
Всё описанное основано на личном опыте настройки и эксплуатации подобных систем. Ни у кого ничего не смотрел, лучших практик не знаю. Придумал всё сам и сделал, как посчитал нужным. Так что не нужно это воспринимать как оптимальное решение.
#1с #postgresql
Server Admin
Установка 1С на Linux (Debian) + PostgreSQL
Пошаговое руководство по настройке Сервера 1С на Debian + PostgreSQL с примерами эксплуатации: мониторинг, бэкапы и т.д.
Очень простой в установке и использовании инструмент для анализа работы СУБД Postgres — pgCenter. Это open source разработка нашего соотечественника Алексея Лесовского, который сейчас трудится в PostgresPro. Он давно известен своим проектом zabbix-extensions (проект давно заброшен и неактуален), где собрана куча скриптов для мониторинга всего и вся в Linux.
PgCenter — набор утилит командной строки, которые позволяют анализировать состояние СУБД в режиме реального времени, наподобие программы top и других подобных инструментов.
PgCenter пригодится как обычным админам, чтобы быстро оценить состояние СУБД (использование ресурсов, просмотр ошибок и т.д.), так и DBA для детального изучения (встроенная статистика) и решения проблем (долгие транзакции, конфликты репликации и т.д.).
В репозитории автоматически собираются rpm и deb пакеты для локальной установки, а также Docker образы. Попробовать проще всего вот так:
У автора есть ещё несколько полезных утилит. Скорее всего напишу о них отдельно:
◽Noisia — генератор нагрузки PostgreSQL.
◽pgSCV — экспортёр метрик для Prometheus и Victoriametrics.
◽pgstats.dev — веб проект с описанием метрик Postgres для мониторинга.
⇨ Исходники
#postgresql
PgCenter — набор утилит командной строки, которые позволяют анализировать состояние СУБД в режиме реального времени, наподобие программы top и других подобных инструментов.
PgCenter пригодится как обычным админам, чтобы быстро оценить состояние СУБД (использование ресурсов, просмотр ошибок и т.д.), так и DBA для детального изучения (встроенная статистика) и решения проблем (долгие транзакции, конфликты репликации и т.д.).
В репозитории автоматически собираются rpm и deb пакеты для локальной установки, а также Docker образы. Попробовать проще всего вот так:
# docker run -it --rm lesovsky/pgcenter:latest pgcenter top \-h 1.2.3.4 -U user -d dbnameУ автора есть ещё несколько полезных утилит. Скорее всего напишу о них отдельно:
◽Noisia — генератор нагрузки PostgreSQL.
◽pgSCV — экспортёр метрик для Prometheus и Victoriametrics.
◽pgstats.dev — веб проект с описанием метрик Postgres для мониторинга.
⇨ Исходники
#postgresql
