Прочитал на 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
Делюсь с вами простым и удобным скриптом для автоматического бэкапа mysql баз с помощью mysqldump - AutoMySQLBackup. Это обычный bash скрипт, который упрощает рутинные задачи по бэкапу, предлагая встроенный функционал.
https://github.com/sixhop/AutoMySQLBackup
Основные возможности скрипта:
▪ Сжимает бэкапы баз и раскладывает их по отдельным директориям.
▪ Поддерживает многопоточные архиваторы типа pigz, позволяет управлять количеством потоков.
▪ Автоматически ротирует дневные, недельные, месячные архивы по заданным параметрам.
▪ Позволяет использовать ключи mysqldump.
▪ Умеет хранить настройки в отдельном конфигурационном файле.
▪ Можно гибко управлять набором баз для бэкапа, вручную указывая их или управляя списком с помощью шаблонов.
▪ Умеет отправлять результаты своей работы по почте.
▪ Может шифровать дампы указанным ключом.
▪ Запуск своего скрипта до или после выполнения бэкапа.
Вот простой конфиг для ежедневного бэкапа баз mysql за исключением performance_schema и information_schema. Ежедневные бэкапы хранятся 7 дней, недельные 31 день, месячные год.
После работы сккрипта в директории /mnt/backup будет создана структура директорий:
◽ daily - ежедневные бэкапы, где каждая база будет в своей директории;
◽ fullschema - только структура всех баз данных;
◽ latest - если указать соответствующую настройку, то в этой директории всегда будут лежать бэкапы от последнего запуска. Удобно отсюда их забирать куда-то в другое место сразу после окончания бэкапа.
◽ monthly - месячные бэкапы;
◽ status - список баз каждого запущенного бэкапа;
◽ tmp - для временных файлов;
◽ weekly - недельные бэкапы;
Рекомендую так же прочитать мою заметку про выбор параметров для mysqldump. Там есть важные моменты, которые влияют на успешность создания дампа.
#bash #mysql #backup
https://github.com/sixhop/AutoMySQLBackup
Основные возможности скрипта:
▪ Сжимает бэкапы баз и раскладывает их по отдельным директориям.
▪ Поддерживает многопоточные архиваторы типа pigz, позволяет управлять количеством потоков.
▪ Автоматически ротирует дневные, недельные, месячные архивы по заданным параметрам.
▪ Позволяет использовать ключи mysqldump.
▪ Умеет хранить настройки в отдельном конфигурационном файле.
▪ Можно гибко управлять набором баз для бэкапа, вручную указывая их или управляя списком с помощью шаблонов.
▪ Умеет отправлять результаты своей работы по почте.
▪ Может шифровать дампы указанным ключом.
▪ Запуск своего скрипта до или после выполнения бэкапа.
Вот простой конфиг для ежедневного бэкапа баз mysql за исключением performance_schema и information_schema. Ежедневные бэкапы хранятся 7 дней, недельные 31 день, месячные год.
CONFIG_mysql_dump_username='root'CONFIG_mysql_dump_password='parol'CONFIG_mysql_dump_host='localhost'CONFIG_backup_dir='/mnt/backup'CONFIG_multicore='no'CONFIG_db_names=()CONFIG_db_exclude=( 'performance_schema' 'information_schema' )CONFIG_db_exclude_pattern=()CONFIG_do_monthly='01'CONFIG_do_weekly='7'CONFIG_rotation_daily=6CONFIG_rotation_weekly=31CONFIG_rotation_monthly=360После работы сккрипта в директории /mnt/backup будет создана структура директорий:
◽ daily - ежедневные бэкапы, где каждая база будет в своей директории;
◽ fullschema - только структура всех баз данных;
◽ latest - если указать соответствующую настройку, то в этой директории всегда будут лежать бэкапы от последнего запуска. Удобно отсюда их забирать куда-то в другое место сразу после окончания бэкапа.
◽ monthly - месячные бэкапы;
◽ status - список баз каждого запущенного бэкапа;
◽ tmp - для временных файлов;
◽ weekly - недельные бэкапы;
Рекомендую так же прочитать мою заметку про выбор параметров для mysqldump. Там есть важные моменты, которые влияют на успешность создания дампа.
#bash #mysql #backup
На неделе прослушал интересный доклад с HighLoad ++ 2021 - MySQL orchestrator, ProxySQL от Ситимобил. Тема актуальна только для очень нагруженных сервисов, где много MySQL серверов в кластере, но тем не менее мне понравилось, хоть и вряд ли когда-то пригодится. Качественный рассказ и построение повествования.
Авторы рассказали всю историю поддержки MySQL сервера с одиночного инстанса на старте проекта до довольно сложной структуры. Особенность их схемы в том, что они очень хотели оставить только один Master сервер, не выстраивая Master-Master репликацию. В итоге у них всё получилось. Есть один Master сервер, очень много Slave серверов. А у различных веб приложений свои персональные ProxySQL, которые сглаживают пики запросов, кэшируют и всячески оберегают Master от большой нагрузки.
Видео рекомендую для общего развития. Прошу заметить, что никакого Кубера, хотя им в конце прямо задали вопрос, как вы запускаете свои ProxySQL инстансы, в отдельных подах? Но нет, у них они на железе работают.
Видео - https://www.youtube.com/watch?v=YvbELUvqLm8
Презентация - https://drive.google.com/file/d/1zyC9JLiiRGHuKHmMzPAQu52B0XwIw4o7/view
#видео #mysql
Авторы рассказали всю историю поддержки MySQL сервера с одиночного инстанса на старте проекта до довольно сложной структуры. Особенность их схемы в том, что они очень хотели оставить только один Master сервер, не выстраивая Master-Master репликацию. В итоге у них всё получилось. Есть один Master сервер, очень много Slave серверов. А у различных веб приложений свои персональные ProxySQL, которые сглаживают пики запросов, кэшируют и всячески оберегают Master от большой нагрузки.
Видео рекомендую для общего развития. Прошу заметить, что никакого Кубера, хотя им в конце прямо задали вопрос, как вы запускаете свои ProxySQL инстансы, в отдельных подах? Но нет, у них они на железе работают.
Видео - https://www.youtube.com/watch?v=YvbELUvqLm8
Презентация - https://drive.google.com/file/d/1zyC9JLiiRGHuKHmMzPAQu52B0XwIw4o7/view
#видео #mysql
Я давно уже привык использовать proxy nginx для http подключений. С ней удобно управлять запросами, распределять их на разные сервисы, кэшировать, логировать и мониторить в одном месте. Недавно познакомился с подобным инструментом, только для mysql подключений - ProxySQL.
Одной из полезных возможностей этой программы, помимо распределения подключений, является кэширования запросов. У Mysql серверов есть дефолтная возможность кэширования, но насколько я знаю, работает она либо неэффективно, либо никак. А в последних версиях её вроде бы вообще убрали. Специально не уточнял, но где-то видел в обзорах изменений.
Настроить и запустить в работу ProxySQL достаточно просто.
Сайт - https://proxysql.com/
Исходники - https://github.com/sysown/proxysql/
▶️ Интересные и полезные видео по теме, которые посмотрел сам и могу рекомендовать:
ProxySQL: быстрый кэш запросов в MySQL 8.0 и не только (тут прям конкретная настройка и примеры работы):
https://www.youtube.com/watch?v=QCylrIyiHwg
MySQL orchestrator, ProxySQL – это продукты, которые вам нужны (HighLoad ++, доклад):
https://www.youtube.com/watch?v=YvbELUvqLm8
#mysql
Одной из полезных возможностей этой программы, помимо распределения подключений, является кэширования запросов. У Mysql серверов есть дефолтная возможность кэширования, но насколько я знаю, работает она либо неэффективно, либо никак. А в последних версиях её вроде бы вообще убрали. Специально не уточнял, но где-то видел в обзорах изменений.
Настроить и запустить в работу ProxySQL достаточно просто.
Сайт - https://proxysql.com/
Исходники - https://github.com/sysown/proxysql/
▶️ Интересные и полезные видео по теме, которые посмотрел сам и могу рекомендовать:
ProxySQL: быстрый кэш запросов в MySQL 8.0 и не только (тут прям конкретная настройка и примеры работы):
https://www.youtube.com/watch?v=QCylrIyiHwg
MySQL orchestrator, ProxySQL – это продукты, которые вам нужны (HighLoad ++, доклад):
https://www.youtube.com/watch?v=YvbELUvqLm8
#mysql
Посмотрел на днях очередной доклад с HighLoad ++ 2021, который показался полезным - Как правильно и надежно убить MySQL. Выступление построено в необычной манере, где рассказывают, как гарантированно сделать плохую конфигурацию сервера. Чтобы сделать нормально, надо делать наоборот.
Не могу сказать, что мне понравилось подобное повествование. Авторы явно хотели сделать оригинально, но лично мне воспринималось не очень. Приходилось на ходу в голове прикидывать постоянно, как делать правильно.
Тем не менее, выступление полезное, так как там конкретно указаны параметры, на которые надо обращать внимание при настройке Mysql сервера. Большую часть того, что они рассказывали я и так знал, поэтому и пишу эту рекомендацию.
Это одно из немногих выступлений, которые полезно не только тем, кто работает с Highload. Список параметров, на которые надо обращать внимание в первую очередь пригодится и для обычных баз данных. Например, того же Zabbix, если он у вас с Mysql работает по старой дружбе. Хотя сейчас уже пора переехать на PostgreSQL.
https://www.youtube.com/watch?v=CpBXc5995eg
Презентация
#mysql #видео
Не могу сказать, что мне понравилось подобное повествование. Авторы явно хотели сделать оригинально, но лично мне воспринималось не очень. Приходилось на ходу в голове прикидывать постоянно, как делать правильно.
Тем не менее, выступление полезное, так как там конкретно указаны параметры, на которые надо обращать внимание при настройке Mysql сервера. Большую часть того, что они рассказывали я и так знал, поэтому и пишу эту рекомендацию.
Это одно из немногих выступлений, которые полезно не только тем, кто работает с Highload. Список параметров, на которые надо обращать внимание в первую очередь пригодится и для обычных баз данных. Например, того же Zabbix, если он у вас с Mysql работает по старой дружбе. Хотя сейчас уже пора переехать на PostgreSQL.
https://www.youtube.com/watch?v=CpBXc5995eg
Презентация
#mysql #видео
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).
#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
Иногда возникает задача быстро удалить все таблицы в базе данных mysql, не удаляя саму базу данных. Доступ к базе через консоль. В общем случае удалить конкретную таблицу в базе db можно следующей командой:
Если таблиц немного, то можно поступить и так. Но если их много, то нужен какой-то другой способ. Можно изобрести или поискать какой-то готовый велосипед на bash. Я предлагаю вам свой 😁
Берём mysqldump и делаем дамп только структуры, добавляя информацию об удалении таблиц перед их созданием:
Теперь получить консольные команды на удаление всех таблиц базы данных проще простого. Грепаем получившийся дамп:
То есть выводим все строки, которые начинаются с DROP. Это как раз то, что нам нужно.
Далее можно либо взять только нужные строки с определёнными таблицами для удаления, либо сразу весь вывод отправить в консоль mysql и удалить все таблицы, оставив саму базу данных:
Не забудьте добавить авторизацию, если у вас она не настроена каким-то другим способом:
Таким простым способом, без скриптов, можно прямо в консоли сервера удалить все таблицы из базы данных mysql, не удаляя саму базу.
❓Может возникнуть вопрос, а почему не удалить всё же базу и не создать заново. Причин может быть несколько:
1️⃣ У вас нет прав на создание и удаление баз данных (наиболее частый случай).
2️⃣ Не помните точно параметры базы данных, не хочется вспоминать, искать, как создать новую базу данных с теми же параметрами, что стоят у текущей (мой случай).
Если у вас есть какое-то свое простое решение по удалению таблиц из базы, делитесь в комментариях.
#terminal #mysql
> use db;> drop table00 table01, table02;Если таблиц немного, то можно поступить и так. Но если их много, то нужен какой-то другой способ. Можно изобрести или поискать какой-то готовый велосипед на bash. Я предлагаю вам свой 😁
Берём mysqldump и делаем дамп только структуры, добавляя информацию об удалении таблиц перед их созданием:
# mysqldump --add-drop-table --no-data dbТеперь получить консольные команды на удаление всех таблиц базы данных проще простого. Грепаем получившийся дамп:
# mysqldump --add-drop-table --no-data db | grep ^DROPТо есть выводим все строки, которые начинаются с DROP. Это как раз то, что нам нужно.
Далее можно либо взять только нужные строки с определёнными таблицами для удаления, либо сразу весь вывод отправить в консоль mysql и удалить все таблицы, оставив саму базу данных:
# mysqldump --add-drop-table --no-data db | grep ^DROP | mysql dbНе забудьте добавить авторизацию, если у вас она не настроена каким-то другим способом:
# mysqldump -uuser -ppassword --add-drop-table --no-data db \| grep ^DROP | mysql -uuser -ppassword dbТаким простым способом, без скриптов, можно прямо в консоли сервера удалить все таблицы из базы данных mysql, не удаляя саму базу.
❓Может возникнуть вопрос, а почему не удалить всё же базу и не создать заново. Причин может быть несколько:
1️⃣ У вас нет прав на создание и удаление баз данных (наиболее частый случай).
2️⃣ Не помните точно параметры базы данных, не хочется вспоминать, искать, как создать новую базу данных с теми же параметрами, что стоят у текущей (мой случай).
Если у вас есть какое-то свое простое решение по удалению таблиц из базы, делитесь в комментариях.
#terminal #mysql
Случилась на днях неприятная история, связанная с моей оплошностью. В связи с лихорадочным ценообразованием последних месяцев, приходится периодически делать какие-то переезды. Цены у хостеров стали сильно различаться, так что иногда приходится переезжать.
Один сайт после переезда со сменой ОС стал как-то подозрительно медленно работать в некоторых ситуациях. Пользовательский контент в основном закеширован, поэтому большое внимание проблеме не уделял. А вот в админке отдельные разделы с большими списками стали долго формироваться. Переехал на схожее по параметрам железо, поэтому не понимал, с чем связано такое проседание.
Предстоял разбор полётов, который я постоянно откладывал. Очень не люблю разбираться в производительности базы данных, потому что мало там понимаю. Это очень узкая ниша и без постоянной практики не так то просто ускорить запросы. Начал с просмотра базовой загрузки сервера. Там всё в порядке, никаких просадок нет, ресурсов более чем достаточно.
Потом заглянул в конфиги Mariadb и сначала не понял, а где вообще основная конфигурация. Всё пересмотрел и тут до меня дошло. Я забыл подтюнить СУБД под ресурсы сервера. В итоге MariaDB работала с дефолтными настройками. Если не ошибаюсь, там innodb_buffer_pool_size установлен в 128M. Это очень сильно влияет на производительность.
Скачал mysqltuner и выставил основные параметры в соответствии с объёмом оперативной памяти сервера. Этого оказалось достаточно, чтобы нормализовалась работа. Я этот тюнер использую как калькулятор. С его помощью удобно подобрать параметры innodb_buffer_pool_size и все сопутствующие настройки, а также буферы. И чтобы всё это не потребляло ресурсов больше, чем есть оперативной памяти под нужды СУБД. Если ошибиться, то можно словить OOM Killer, который будет прибивать базу данных.
Полезные ссылки по теме:
- Сравнение mysql vs mariadb
- На что обращать внимание при настройке Mysql
- Производительности Mysql сервера на файловой системе zfs
- индексы в Mysql
- Размещение субд в контейнерах
#mysql #website
Один сайт после переезда со сменой ОС стал как-то подозрительно медленно работать в некоторых ситуациях. Пользовательский контент в основном закеширован, поэтому большое внимание проблеме не уделял. А вот в админке отдельные разделы с большими списками стали долго формироваться. Переехал на схожее по параметрам железо, поэтому не понимал, с чем связано такое проседание.
Предстоял разбор полётов, который я постоянно откладывал. Очень не люблю разбираться в производительности базы данных, потому что мало там понимаю. Это очень узкая ниша и без постоянной практики не так то просто ускорить запросы. Начал с просмотра базовой загрузки сервера. Там всё в порядке, никаких просадок нет, ресурсов более чем достаточно.
Потом заглянул в конфиги Mariadb и сначала не понял, а где вообще основная конфигурация. Всё пересмотрел и тут до меня дошло. Я забыл подтюнить СУБД под ресурсы сервера. В итоге MariaDB работала с дефолтными настройками. Если не ошибаюсь, там innodb_buffer_pool_size установлен в 128M. Это очень сильно влияет на производительность.
Скачал mysqltuner и выставил основные параметры в соответствии с объёмом оперативной памяти сервера. Этого оказалось достаточно, чтобы нормализовалась работа. Я этот тюнер использую как калькулятор. С его помощью удобно подобрать параметры innodb_buffer_pool_size и все сопутствующие настройки, а также буферы. И чтобы всё это не потребляло ресурсов больше, чем есть оперативной памяти под нужды СУБД. Если ошибиться, то можно словить OOM Killer, который будет прибивать базу данных.
Полезные ссылки по теме:
- Сравнение mysql vs mariadb
- На что обращать внимание при настройке Mysql
- Производительности Mysql сервера на файловой системе zfs
- индексы в Mysql
- Размещение субд в контейнерах
#mysql #website
Хочу поделиться с вами очень приятной находкой в виде бесплатной программы для бэкапа SQL баз и обычных файлов - SQLBackupAndFTP. Программа работает под Windows и на самом деле платная, но есть функциональная бесплатная версия с некоторыми ограничениями.
SQLBackupAndFTP умеет:
◽ бэкапить вручную и по расписанию базы данных MSSQL, MySQL, PostgreSQL
◽ складывать бэкапы на FTP, SFTP, FTPS, локальную или сетевую папку, Yandex.Disk
◽ отправлять уведомления на почту
◽ писать лог выполняемых действий
◽ автоматически удалять старые бэкапы
◽ работать через прокси
◽ подключаться к sql серверу и выполнять там sql команды
Основное ограничение бесплатной версии - не более двух баз данных, добавленных в планировщик. Вручную запускать бэкапы можно для неограниченного количества баз. Ещё ограничения бесплатной версии: нет поддержки S3, только полные бэкапы, нет поддержки шифрования.
Я попробовал программу. Скачивается с сайта без всяких регистраций и других ужимок. Настройки очень простые и наглядные. Сама программа выглядит современно и удобно. Порадовала возможность снять бэкап mysql базы, подключившись к веб интерфейсу phpmyadmin. То есть не нужен прямой доступ к базе. Раньше нигде не видел такого функционала.
Программа оставила приятное впечатление. Если вам некритичны ограничения, то можно пользоваться. Уточню ещё раз, что вручную запускать бэкап можно неограниченного количества баз. Вы можете их добавить в интерфейс и запускать время от времени вручную по мере необходимости. Знаю людей, которые базы 1С вручную раз в неделю копируют на Яндекс.Диск. Эта программа может существенно упростить задачу, особенно людям, далёким от IT.
Сайт - https://sqlbackupandftp.com/
#backup #mysql #windows
SQLBackupAndFTP умеет:
◽ бэкапить вручную и по расписанию базы данных MSSQL, MySQL, PostgreSQL
◽ складывать бэкапы на FTP, SFTP, FTPS, локальную или сетевую папку, Yandex.Disk
◽ отправлять уведомления на почту
◽ писать лог выполняемых действий
◽ автоматически удалять старые бэкапы
◽ работать через прокси
◽ подключаться к sql серверу и выполнять там sql команды
Основное ограничение бесплатной версии - не более двух баз данных, добавленных в планировщик. Вручную запускать бэкапы можно для неограниченного количества баз. Ещё ограничения бесплатной версии: нет поддержки S3, только полные бэкапы, нет поддержки шифрования.
Я попробовал программу. Скачивается с сайта без всяких регистраций и других ужимок. Настройки очень простые и наглядные. Сама программа выглядит современно и удобно. Порадовала возможность снять бэкап mysql базы, подключившись к веб интерфейсу phpmyadmin. То есть не нужен прямой доступ к базе. Раньше нигде не видел такого функционала.
Программа оставила приятное впечатление. Если вам некритичны ограничения, то можно пользоваться. Уточню ещё раз, что вручную запускать бэкап можно неограниченного количества баз. Вы можете их добавить в интерфейс и запускать время от времени вручную по мере необходимости. Знаю людей, которые базы 1С вручную раз в неделю копируют на Яндекс.Диск. Эта программа может существенно упростить задачу, особенно людям, далёким от IT.
Сайт - https://sqlbackupandftp.com/
#backup #mysql #windows
Решил упростить себе задачу и подготовить список настроек, которые надо обязательно проверить при настройке одиночного mysql/mariadb сервера. Я не буду давать описания настроек и советовать какие-то значения, потому что это очень большой объём информации. Вы сами сможете её найти в интернете и подогнать под свою ситуацию.
Первое, что надо сделать - сбалансировать потребление памяти сервером. Не обязательно делать это вручную. Можно воспользоваться скриптом mysqltuner. Перечислю параметры Global + Thread, из которых складывается потребление памяти:
Global:
Эти значения просто суммируются.
Thread:
Эти значения суммируются и умножаются на
Как я уже сказал, не обязательно их все править. Можно воспользоваться mysqltuner или оставить дефолтные значения, а вручную указать наиболее критичные - innodb_buffer_pool_size, max_connections. Остальные параметры mysqltuner подскажет, как подогнать под основные. Innodb_buffer_pool_size подбирают таким образом, чтобы с учётом всех остальных параметров суммарное потребление оперативной памяти не выходило за отведённые для Mysql Server пределы.
Обязательно проверяю:
Если не требуются подключения извне, привязываю к localhost.
Проверяю расположение логов и чаще всего сразу добавляю лог медленных запросов:
Указываю нужную кодировку. Сейчас вроде бы везде utf8mb4 по умолчанию стоит, раньше utf8 ставили.
Важные параметры, которые заметно влияют на производительность:
Они привязаны к количеству соединений и таблиц в базе. Для того же Bitrix эти параметры имеют высокие значения и часто упираются в системные лимиты ОС для отдельного процесса. Их нужно тоже увеличить. Например вот так:
Содержимое файла:
Ещё один параметр, на который стоит обратить внимание:
Он регулирует размер и рост файла с временным табличным пространством. Этот файл иногда может вырастать до огромных размеров и вызывать нехватку свободного места. Имеет смысл его сразу ограничить до разумных пределов. Вот пример ограничения размера в 2 ГБ и роста частями по 12 Мб
Это основное, на что я обращаю внимание. Более детальные настройки делаются, если возникают какие-то проблемы.
#mysql
Первое, что надо сделать - сбалансировать потребление памяти сервером. Не обязательно делать это вручную. Можно воспользоваться скриптом mysqltuner. Перечислю параметры Global + Thread, из которых складывается потребление памяти:
Global:
innodb_buffer_pool_sizeinnodb_log_file_sizekey_buffer_sizeinnodb_log_buffer_sizequery_cache_sizearia_pagecache_buffer_sizeЭти значения просто суммируются.
Thread:
sort_buffer_sizejoin_buffer_sizeread_buffer_sizeread_rnd_buffer_sizemax_allowed_packetthread_stackЭти значения суммируются и умножаются на
max_connections. Как я уже сказал, не обязательно их все править. Можно воспользоваться mysqltuner или оставить дефолтные значения, а вручную указать наиболее критичные - innodb_buffer_pool_size, max_connections. Остальные параметры mysqltuner подскажет, как подогнать под основные. Innodb_buffer_pool_size подбирают таким образом, чтобы с учётом всех остальных параметров суммарное потребление оперативной памяти не выходило за отведённые для Mysql Server пределы.
Обязательно проверяю:
bind-address = 127.0.0.1Если не требуются подключения извне, привязываю к localhost.
Проверяю расположение логов и чаще всего сразу добавляю лог медленных запросов:
log_error = /var/log/mysql/error.logslow_query_logslow_query_log_file = /var/log/mysql/slow.loglong_query_time = 2.0Указываю нужную кодировку. Сейчас вроде бы везде utf8mb4 по умолчанию стоит, раньше utf8 ставили.
character-set-server = utf8mb4collation-server = utf8mb4_general_ciВажные параметры, которые заметно влияют на производительность:
open_files_limittable_open_cache Они привязаны к количеству соединений и таблиц в базе. Для того же Bitrix эти параметры имеют высокие значения и часто упираются в системные лимиты ОС для отдельного процесса. Их нужно тоже увеличить. Например вот так:
# mkdir /etc/systemd/system/mysqld.service.d# touch limit.confСодержимое файла:
[Service]LimitNOFILE=65535Ещё один параметр, на который стоит обратить внимание:
innodb_temp_data_file_pathОн регулирует размер и рост файла с временным табличным пространством. Этот файл иногда может вырастать до огромных размеров и вызывать нехватку свободного места. Имеет смысл его сразу ограничить до разумных пределов. Вот пример ограничения размера в 2 ГБ и роста частями по 12 Мб
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2GЭто основное, на что я обращаю внимание. Более детальные настройки делаются, если возникают какие-то проблемы.
#mysql
Существуют разные подходы к мониторингу. Можно настраивать одну универсальную систему и всё замыкать на неё. Это удобно в том плане, что всё в одном месте. Но мониторинг каждого отдельного элемента будет не самым лучшим.
Другой подход - для каждого продукта использовать тот мониторинг, который заточен именно под него. Например, такой мониторинг есть для 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
