Оптимизация конфигурации mysql

MySQLTuner

MySQLTuner — скрипт, анализирующий статистику работы MySQL, и, на основе полученных данных, выдающий рекомендации по настройке. Для получения более надёжных рекомендаций нужно, чтобы MySQL сервер был запущен по крайней мере в течение 24-48 часов без изменения конфигурации. Однако даже в таком случае внимательно анализируйте рекомендации MySQLTuner.

MySQLTuner нужно установить или загрузить.

Установка MySQLTuner:

yum install mysqltuner

или загрузка:

wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.p

Во время загрузки возможна ошибка вида:

ERROR: cannot verify raw.githubusercontent.com's certificate, issued by '/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA': Unable to locally verify the issuer's authority. To connect to raw.githubusercontent.com insecurely, use `--no-check-certificate'.

Тогда запустите загрузку с ключом —no-check-certificate:

wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl --no-check-certificate

Запуск MySQLTuner, если он был установлен:

mysqltuner

или

mysqltuner --user root --pass rootpassword

Запуск MySQLTuner, если он был скачан:

perl mysqltuner.pl

или

perl mysqltuner.pl --user root --pass rootpassword

Оптимизация схемы MySQL:

40. Используйте в своей базе данных trim.
41. Архивировать старые данные – убрать излишние строки возврата или поиска по запросам.
42. Поместите индексы на свои данные.
43. Не злоупотребляйте индексами, сравните с вашими запросами.
44. Сжатие текстовых и блобных типов данных – для экономии места и уменьшения числа операций чтения с диска.
45. UTF 8 и UTF16 медленнее латинского1.
46. Используйте триггеры экономно.
47. Сохраняйте избыточные данные до минимума – не дублируйте данные без необходимости.
48. Используйте связывание таблиц, а не расширение строк.
49

Обратите внимание на ваши типы данных, используйте наименьший возможный для ваших реальных данных.
50. Отделите данные BLOB/текста от других данных, если другие данные часто используются для запросов, а объекты BLOB/Text – нет.
51

Часто проверяйте и оптимизируйте таблицы.
52. Часто переписывайте таблицы InnoDB для оптимизации.
53. Иногда быстрее удалить индексы при добавлении столбцов, а затем добавить индексы обратно.
54. Используйте разные механизмы хранения для разных нужд.
55. Используйте механизм хранения ARCHIVE для журналирования таблиц или аудита таблиц – это гораздо более эффективно для записи.
56. Храните данные сеанса в memcache, а не в MySQL – memcache допускает автоматическое истечение значений и не позволяет создавать дорогостоящие операции чтения и записи в MySQL для временных данных.
57. Используйте VARCHAR вместо CHAR при хранении строк переменной длины – для экономии места, поскольку CHAR – это фиксированная длина, а VARCHAR – нет (на utf8 это не влияет).
58. Вносите изменения схемы постепенно – небольшое изменение может иметь радикальные последствия.
59. Протестируйте все изменения схемы в среде разработки, которая отражает производство.
60. НЕ изменяйте произвольно значения в вашем конфигурационном файле, это может иметь катастрофические последствия.
61. Иногда меньше – это больше в конфигурациях MySQL.
62. В случае сомнений используйте общий конфигурационный файл MySQL.

Количество «звезд» по времени

Совместимость

MySQL 8 (полная поддержка, проверка пароля не работает)
MySQL 5.7 (полная поддержка)
MySQL 5.6 (полная поддержка)
MySQL 5.5 (полная поддержка)
MariaDB 10.4 (полная поддержка)
MariaDB 10.3 (полная поддержка)
MariaDB 10.2 (полная поддержка)
MariaDB 10.1 (полная поддержка)
MariaDB 10.0 (полная поддержка, последние 6 месяцeв)
MariaDB 5.5 (полная поддержка, но без поддержки от MariaDB)
Percona Server 8.0 (полная поддержка, проверка пароля не работает)
Percona Server 5.7 (полная поддержка)
Percona Server 5.6 (полная поддержка)
Percona XtraDB cluster (частичная поддержка, нет тестового окружения)
Mysql Replications (частичная поддержка, нет тестового окружения)
Galera replication (частичная поддержка, нет тестового окружения)
MySQL 3.23, 4.0, 4.1, 5.0, 5.1, 5.5 (частичная поддержка — устаревшие версии)

*** НЕ ПОДДЕРЖИВАЕМЫЕ ОКРУЖЕНИЯ — НУЖНА ПОМОЩЬ С НИМИ ***

Windows не поддерживается на данное время (Необходима помощь!!!!!)
Облачные сервисы(cloud based) не поддерживаются на данное время (Необходима помощь!!!!!)

*** МИНИМАЛЬНЫЕ ТРЕБОВАНИЯ ***

Операционная система семейства Unix/Linux (протестировано на Linux, различных вариациях BSD и Solaris)
Неограниченный доступ на чтение для MySQL-сервера (Для работы с MySQL < 5.1 требуется root-доступ к серверу)

Пожалуйста, прочитайте раздел ЧаВо, который расположен чуть ниже.

5 последних уроков рубрики «Разное»

Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.
Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.
Создание вебсайта — процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.
Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Опциональная установка Performance schema и Sysschema для MariaDB 10.x

Sysschema не установлена по умолчанию на MariaDB 10.x.
А performance schema по умолчанию отключена в MariaDB. Для активации ее требуется включить в конфигурационном файле my.cnf:

mysqld
performance_schema = on

Вы можете создать новую базу данных sys, содержащую очень полезный взгляд на Performance schema следующими командами:

curl "https://codeload.github.com/FromDual/mariadb-sys/zip/master" > mariadb-sys.zip
# check zip file
unzip -l mariadb-sys.zip
unzip mariadb-sys.zip
cd mariadb-sys-master/
mysql -u root -p < ./sys_10.sql

Ошибки и их решения при установке performance schema

 ERROR at line 21: Failed to open file './tables/sys_config_data_10.sql -- ported', error: 2
 Посмотрите на #452 решение, данное @ericx

Сравнение вашей конфигурации на нескольких серверах

Если вы работаете с несколькими серверами MySQL, вы, возможно, хотите, чтобы конфигурации на всех серверах были одинаковы. Ручное сравнение конфигурации может быть довольно утомительным. К нашему счастью, у Percona есть утилита pt-config-diff.

В базовом варианте утилита принимает два файла, и сравнивает их. Возьмем за основу два следующих примера:

log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
log-queries-not-using-indexes = 1

log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
log-queries-not-using-indexes = 0

Если мы запустим команду , то мы получим примерно такой ответ:

1 разница в конфиге
Переменная                 /server1/etc/mysql/my.cnf /server2/etc/mysql/my.cnf
========================= =========== ====
log_queries_not_using_... 1           0

Использованный пример, разумеется, очень прост. Но если вам необходимо оптимизировать множество серверов, то данная утилита может прийти вам на помощь, когда необходимо настраивать большое число переменных.

Установка

Скачайте MySQLTuner:

Для удобства можно воспользоваться штатными репозиториями и установить MySQLTuner.

Для Debian/Ubuntu:

Для CentOS:

Разрешите выполнение скрипта (Если производилось скачивание скрипта):

Запустите скрипт mysqltuner.pl. Вам будет предложено ввести имя пользователя и пароль администратора MySQL:

Если производилось скачивание скрипта:

Если производилась установка:

Если возникла ошибка:

Запустите с с ключом —no-check-certificate:

Скрипт вернет результаты анализа, аналогичные представленным ниже:

MySQLTuner предлагает способы повышения производительности базы данных. Если самостоятельно обновить конфигурацию базы данных затруднительно, то выполнение рекомендаций MySQLTuner является одним из безопасных способов повышения производительности.

Используйте статичные таблицы

Статичная таблица это обычная таблица в базе, за исключеним того, что каждое поле в таблице имеет фиксированный размер. Если в таблице есть колонки, не фиксированной длины, к примеру, это могут быть: VARCHAR, TEXT, BLOB, она перестает быть статичной, и будет обрабатываться MySQL немного иначе. Статичные таблицы, или их можно ещё назвать таблицами фиксированного размера работают быстрее не статичных. Записи из таких таблицах будут просматриваться быстрее, при необходимости выбора нужной строки MySQL быстро вычислит её позицию. Если поле имеет не фиксированный размер, то в этом случае поиск производиться по индексу. Есть и другие плюсы использования статических таблиц, дело в том, что эти таблицы проще кэшируются, а так же восстанавливаются после падения базы данных.

Примеры использования

Пример: Минимальный локальный запуск

perl mysqltuner.pl --host 127.0.0.1

Конечно, вам нужно будет добавить права на выполнение скрипта (chmod +x mysqltuner.pl), если вы хотите запускать его напрямую, без указания perl.

Пример: Минимальный удаленный запуск

perl mysqltuner.pl --host targetDNS_IP --user admin_user --pass admin_password

Пример: Включение максимамльного вывода информации о MySQL/MariaDb без отладочной информации

perl mysqltuner.pl --verbose
perl mysqltuner.pl --buffers --dbstat --idxstat --sysstat --pfstat --tbstat

Пример: Включение проверки на CVE уязвимости для MariaDB или MySQL

perl mysqltuner.pl --cvefile=vulnerabilities.csv

Пример: Запись результата в файл с отображением информации

perl mysqltuner.pl --outputfile /tmp/result_mysqltuner.txt

Пример: Запись результата в файл без вывода информации

perl mysqltuner.pl --silent --outputfile /tmp/result_mysqltuner.txt

perl mysqltuner.pl --silent --reportfile /tmp/result_mysqltuner.txt --template=/tmp/mymodel.tmpl

Пример: Включение вывода отладочной информации

perl mysqltuner.pl --debug

Пример: Обновление MySQLTuner и файлов с данными (пароль и cve), если необходимо.

perl mysqltuner.pl --checkversion --updateversion

Процедуры резервного копирования MySQL:

87. Резервное копирование со вторичного реплицируемого сервера.
88. Остановите репликацию во время резервного копирования, чтобы предотвратить несоответствия в зависимостях данных и внешних ограничениях.
89. Полностью остановите MySQL и сделайте резервную копию файлов базы данных.
90. Резервное копирование двоичных журналов одновременно с дамп-файлом, если используется дамп MySQL – чтобы убедиться, что репликация не прерывается.
91. Не доверяйте снимку LVM для резервных копий – это может привести к несоответствиям данных, что приведет к проблемам в будущем.
92. Создавайте дампы для каждой таблицы, чтобы упростить восстановление одной таблицы, если данные изолированы от других таблиц.
93. Используйте –opt при использовании mysqldump.
94. Проверьте и оптимизируйте таблицы перед резервным копированием.
95. При импорте временно отключите внешние ограничения для более быстрого импорта.
96. При импорте временно отключите уникальные проверки для более быстрого импорта.
97. Рассчитайте размер данных и индексов базы данных/таблиц после каждой резервной копии, чтобы отслеживать рост.
98. Следите за репликацией подчиненного устройства на наличие ошибок и задержек с помощью скрипта cron.
99. Регулярно делайте резервные копии.
100. Регулярно проверяйте свои резервные копии.

И наконец 101 : Выполнение мониторинга MySQL.

Настройка MySQL

При изменении конфигурации MySQL следует внимательно относиться к изменениям и их влиянию на базу данных. Даже при выполнении инструкций таких программ, как MySQLTuner, лучше иметь некоторое понимание процесса.

С порядком анализа можно ознакомиться .

Конфигурационный файл MySQL хранится в директории:

Для CentOS:

В этот файл могут быть внесены изменения, основанные на рекомендациях MySQLTuner в пункте Variables to adjust секции Recommendations. Если какого-либо параметра нет в файле my.cnf, допишите его.

После внесения изменений в my.cnf перезагрузите MySQL-сервер:

Debian/Ubuntu и CentOS 6:

CentOS 7:

Обратите внимание! Прежде чем проводить обновление конфигурации MySQL, желательно создать бэкап.

Для наиболее эффективного использования возможностей MySQLTuner желательно производить небольшие изменения за раз, а затем проводить повторный анализ. Таким итеративным способом можно будет добиться наилучших результатов при настройке MySQL.

При этом, для того чтобы данные были корректны, необходимо, чтобы сервер MySQL проработал не менее 24 часов без перезагрузок и смены параметров конфигурации перед следующим анализом.

MySQLTuner

MySQLTuner — еще одна утилита из набора Perkona Toolkit. Эта утилита проанализирует быстродействие вашего MySQL сервера, и предложит варианты его улучшения. По-хорошему, запускать данную утилиту стоит тогда, когда ваш MySQL сервер проработал несколько дней. После изменения конфигурации надо подождать еще несколько дней, и запустить утилиту снова.

Давайте запустим и посмотрим, как себя показывает текущая конфигурация MySQL.

>>  MySQLTuner 1.2.0 - Major Hayden 
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
 Logged in using credentials from debian maintenance account.

-------- Общая статистика --------------------------------------------------
 Проверка версии скрипта MySQLTuner пропущена
 Сейчас запущена поддерживаемая версия MySQL  5.5.35-0ubuntu0.12.04.2-log
 Работа с 64 битной архитектурой

-------- Статистика движка хранилища -------------------------------------------
 Статус: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
 Данных в таблицах MyISAM: 941M (Таблиц: 399)
 Данных в таблицах InnoDB: 2G (Таблиц: 891)
 Данных в таблицах PERFORMANCE_SCHEMA: 0B (Таблиц: 17)
 Всего фрагментированных таблиц: 913

-------- Метрики производительности -------------------------------------------------
 Работает: 4д 1ч 41м 1с (64K q , 791 соед., TX: 119M, RX: 71M)
 Чтений / Записей: 71% / 29%
 Всего буферов: 192.0M глобально + 2.8M на поток (151 максимально потоков)
 Максимально возможное использование памяти: 607.2M (10% из установленной памяти)
 Медленных запросов: 4% (3K/64K)
 Наибольшее использование доступных соединений: 3% (6/151)
 Размер буферного ключа / всего индексов MyISAM: 16.0M/309.5M
 Процент попадания в буферный ключ: 86.9% (14M закешировано / 1M чтений)
 Эффективность кеша запросов: 58.9% (31K закешировано / 53K выборок)
 Очисток кеша запросов за день: 0
 Сортировки, требующие временных таблиц: 0% (0 временных сортировок / 808 сортировок)
 Временных таблиц создано на диске: 6% (99 на диске / 1K всего)
 Попадания в кеш потока: 99% (6 создано/ 791 соединений)
 Попаданий в кеш таблиц: 6% (400 открытий / 5K открыто)
 Процент использования лимита открытия файлов: 3% (695/20K)
 Блокировок таблиц, которые удалось провести сразу: 99% (47K сразу / 47K блокировок)
 Размер данных InnoDB / буферный пул: 2.0G/128.0M

-------- Рекомендации -----------------------------------------------------
Общие рекомендации:
    Запустите запрос OPTIMIZE TABLES для дефрагментации таблиц чтобы улучшить производительность
    Постепенно увеличивайте table_cache, чтобы избежать ограничений файловых дескрипторов
Переменные для настройки:
    key_buffer_size (> 309.5M)
    table_cache (> 400)
    innodb_buffer_pool_size (>= 2G)

Сначала мы видим результаты теста MySQLTuner. На основе этих результатов MySQLTuner дает некоторые рекомендации по изменению конфигурации, что приведет к улучшению производительности базы данных

Прошу принять во внимание, что конфигурация бузы данных — это всегда метод проб и ошибок, и проверка, что все работает как надо. Также не забудьте вернуться к проверке базы данных этим скриптом через несколько дней после изменения конфигурационных параметров, чтобы проверить, улучшилась ли ситуация, и не нужны ли дополнительные настройки

Шардинг

Шардинг — это принцип масштабирования базы данных, когда данные разделяются по разным серверам. В нашем распоряжении есть два подхода:

Вертикальный шардинг

Его стоит использовать в первую очередь. Это простое распределение таблиц по серверам. Например, вы помещаете таблицу на одном сервере, а таблицу на другом. В этом случае группы таблиц, по которым выполняются , должны находится на одном сервере.

Горизонтальный шардинг

Этот тип шардинга следует использовать следующим этапом. На этом этапе очень большие таблицы, которые перестают помещаться на одном сервере, разделяют на части и помещают разные их части на разных серверах. Это усложняет логику приложения, однако мир еще не придумал лучших механизмов масштабирования.

Кэширование

Очень популярным методом оптимизации производительности является кэширование.

Внутренний кэш MySQL

Перед тем как использовать внешнее решение, подумайте, стоит ли использовать внутренний кэш MySQL. Его имеет смысл включать в тех случаях, когда MySQL работает с очень большим количеством чтений (), но не очень большим (как минимум в 10 раз меньше) записей (, и ).

Настройка кэша выполняется с помощью параметра.

Внешние решения

Однако будьте осторожны. Кэширование — это часто не решение проблемы, а ее откладывание. Медленный запрос становится еще медленнее, а его влияние (при сбросе кэша) — менее прогнозируемым.

Tools That Can Help Optimize MySQL

In order to determine if your MySQL database needs to be reconfigured, it is best to look at how your resources are performing now. This can be done with the
top command or with the Linode
Longview service. At the very least, you should familiarize yourself with the RAM and CPU usage of your server, which can be discovered with these commands:

MySQLTuner

The
MySQLTuner script assesses your MySQL installation, and then outputs suggestions for increasing your server’s performance and stability.

Download the MySQLTuner script:
Change the scripts permissions to be executable:
Run the script. You will be prompted to enter in your MySQL administrative login and password:
The script will return results similar to the output below:

MySQLTuner offers suggestions regarding how to better the database’s performance. If you are wary about updating your database on your own, following MySQLTuner’s suggestions is one of the safer ways to improve your database performance.

Разделяйте объемные запросы INSERT и DELETE

Выполнение большого объема запросов такого рода может привести к блокировке таблицы, вследствие чего, к неправильной работы приложения в целом. Параллельные запросы на веб-сервер могут порождать дополнительное обращение к таблице. Если таблица заблокирована предыдущим запросом, последующие запросы выстраиваются в очередь, и как следствие это проявляется в виде торможения сайта, а то и падения сервера.
Если вам необходимо сделать множество запросов, постарайтесь контролировать их, отдавая небольшими сериями, а не скидывать всё на базу данных. При этом возможно ваш запрос будет выполняться дольше, но это менее скажется на других пользователях.
Пример:

while (1){
	mysql_query("DELETE FROM logs WHERE log_date <= '2015-07-20' LIMIT 1000");
	if (mysql_affected_rows() == 0){
		// записи удалены успешно
		break;
	}
	usleep(50000); // делаем небольшую паузу
}

Оптимизация и индексы

Прежде всего убедитесь, что вы используете все стандартные возможности базы данных. Правильная работа с индексами даст огромные приросты в производительности. Сотни и даже тысячи раз. Освобождая при этом ресурсы для других задач. Сегодня стоимость жестких дисков постоянно снижается, а требования к скорости постоянно растут.

Не спешите оптимизировать все запросы заранее. Используйте лог медленных запросов, чтобы понять, где существуют реальные проблемы.

Сразу после установки MySQL не забудьте оптимизировать основные параметры. Стандартная настройка очень базовая и ориентирована на скромное железо и жесткие требования к сохранности.

MySQLTuner

Давайте запустим и посмотрим, как себя показывает текущая конфигурация MySQL.

>>  MySQLTuner 1.2.0 - Major Hayden 
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
 Logged in using credentials from debian maintenance account.

-------- Общая статистика --------------------------------------------------
 Проверка версии скрипта MySQLTuner пропущена
 Сейчас запущена поддерживаемая версия MySQL  5.5.35-0ubuntu0.12.04.2-log
 Работа с 64 битной архитектурой

-------- Статистика движка хранилища -------------------------------------------
 Статус: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
 Данных в таблицах MyISAM: 941M (Таблиц: 399)
 Данных в таблицах InnoDB: 2G (Таблиц: 891)
 Данных в таблицах PERFORMANCE_SCHEMA: 0B (Таблиц: 17)
 Всего фрагментированных таблиц: 913

-------- Метрики производительности -------------------------------------------------
 Работает: 4д 1ч 41м 1с (64K q , 791 соед., TX: 119M, RX: 71M)
 Чтений / Записей: 71% / 29%
 Всего буферов: 192.0M глобально + 2.8M на поток (151 максимально потоков)
 Максимально возможное использование памяти: 607.2M (10% из установленной памяти)
 Медленных запросов: 4% (3K/64K)
 Наибольшее использование доступных соединений: 3% (6/151)
 Размер буферного ключа / всего индексов MyISAM: 16.0M/309.5M
 Процент попадания в буферный ключ: 86.9% (14M закешировано / 1M чтений)
 Эффективность кеша запросов: 58.9% (31K закешировано / 53K выборок)
 Очисток кеша запросов за день: 0
 Сортировки, требующие временных таблиц: 0% (0 временных сортировок / 808 сортировок)
 Временных таблиц создано на диске: 6% (99 на диске / 1K всего)
 Попадания в кеш потока: 99% (6 создано/ 791 соединений)
 Попаданий в кеш таблиц: 6% (400 открытий / 5K открыто)
 Процент использования лимита открытия файлов: 3% (695/20K)
 Блокировок таблиц, которые удалось провести сразу: 99% (47K сразу / 47K блокировок)
 Размер данных InnoDB / буферный пул: 2.0G/128.0M

-------- Рекомендации -----------------------------------------------------
Общие рекомендации:
    Запустите запрос OPTIMIZE TABLES для дефрагментации таблиц чтобы улучшить производительность
    Постепенно увеличивайте table_cache, чтобы избежать ограничений файловых дескрипторов
Переменные для настройки:
    key_buffer_size (> 309.5M)
    table_cache (> 400)
    innodb_buffer_pool_size (>= 2G)

Репликация

Несмотря на то, что репликация может помочь справиться с нагрузкой, ее лучше для этого не применять. Нужно помнить, что наряду с масштабированием у вас всегда будет стоять вопрос доступности. Если реплика, которая помогает обслуживать запросы, выйдет из строя, что случится с системой?

С другой стороны, реплика как раз позволяет обеспечить высокую доступность. Один из подходов выглядит так:

Использовать master-slave-репликацию для каждого сервера БД.
Приложение всегда работает только с мастером.
Если мастер выходит из строя, приложение переключается на слейв.
Мы в это время поднимаем сломанный сервер и превращаем его в слейв (как это правильно сделать).

Таким образом, в новой схеме мастер и слейв поменялись местами, а приложение (то есть его пользователи) не заметило никаких проблем.

5 последних уроков рубрики «Разное»

Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.
Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.
Создание вебсайта — процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.
Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Сравнение вашей конфигурации на нескольких серверах

В базовом варианте утилита принимает два файла, и сравнивает их. Возьмем за основу два следующих примера:

log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
log-queries-not-using-indexes = 1

log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
log-queries-not-using-indexes = 0

Если мы запустим команду , то мы получим примерно такой ответ:

1 разница в конфиге
Переменная                 /server1/etc/mysql/my.cnf /server2/etc/mysql/my.cnf
========================= =========== ====
log_queries_not_using_... 1           0

Улучшения путем конфигурации

В Percona Toolkit есть инструмент под названием pt-variable-advisor. С помощью этой утилиты вы можете проанализировать вашу текущую конфигурацию, и получить рекомендации по настройке параметров. проверит вашу конфигурацию на основе ряда правил, заданных в Percona. Для того, чтобы посмотреть полный список правил, можно глянуть в .

Давайте запустим утилиту на стандартной конфигурации MySQL, и посмотрим на ее рекомендации:

# ПРЕДУПРЕЖДЕНИЕ delay_key_write: Блоки индексов MyISAM очищаются только при необходимости.

# ПРЕДУПРЕЖДЕНИЕ innodb_log_file_size: Размер файла лога InnoDB установлен размером по умолчанию, что не подходит для продакшен-серверов.

# ЗАМЕЧАНИЕ log_warnings-2: Значение должно быть выставлено больше 1, чтобы в лог попадали только особые события, напримр, обрыв соединения.

# ЗАМЕЧАНИЕ max_binlog_size: Параметр max_binlog_size меньше, чем значение по умолчанию в 1Гб.

# ЗАМЕЧАНИЕ max_connect_errors: Параметр стоило бы выставить в максимальное значение, которое может позволить ваша платформа.

# ПРЕДУПРЕЖДЕНИЕ slave_net_timeout: Параметр выставлен в слишком большое значение.

# ЗАМЕЧАНИЕ sort_buffer_size-1: Переменную лучше оставить в том значени, с каким она идет по умолчанию. Необходимость изменения может подсказать только специалист.

# ЗАМЕЧАНИЕ innodb_data_file_path: Автоматическое увеличение размеров файлов InnoDB может привести к увеличению используемого дискового пространства, что довольно тяжело исправить позже.

# ЗАМЕЧАНИЕ innodb_flush_method: Для большинства продакшен-серверов, использующих InnoDB, переменная innodb_flush_method должна быть выставлена в O_DIRECT, чтобы избежать двойной буферизации, кроме случаем, когда производительность системы ввода-вывода страдает.

# ПРЕДУПРЕЖДЕНИЕ log_bin: Двоичное логирование отключено, так что функции восстановления и репликации отключены.

На основе данных замечаний можно начинать улучшение конфигурации. Для более детализированного описания каждой переменной можно обратиться к документации MySQL.

Оптимизация конфигурации mysql

MySQLTuner

Оптимизация схемы MySQL:

Количество «звезд» по времени

Совместимость

5 последних уроков рубрики «Разное»

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

Опциональная установка Performance schema и Sysschema для MariaDB 10.x

Сравнение вашей конфигурации на нескольких серверах

Установка

Используйте статичные таблицы

Примеры использования

Рекомендации конфигурации

MySQL выделено 4GB RAM

MySQL выделено 8GB RAM

Процедуры резервного копирования MySQL:

Настройка MySQL

MySQLTuner

Шардинг

Вертикальный шардинг

Горизонтальный шардинг

Кэширование

Внутренний кэш MySQL

Внешние решения

Tools That Can Help Optimize MySQL

MySQLTuner

Разделяйте объемные запросы INSERT и DELETE

Оптимизация и индексы

MySQLTuner

Репликация

5 последних уроков рубрики «Разное»

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

Сравнение вашей конфигурации на нескольких серверах

Улучшения путем конфигурации