Привет, Вы узнаете о том , что такое техники применяющиеся для отладки production приложений используемые sql, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое техники применяющиеся для отладки production приложений используемые sql , настоятельно рекомендую прочитать все из категории Методы выявления ошибок в SQL приложении.

К сожалению не всегда можно отловить ошибку на стадии тестирования. Часто они проявляют себя только при реальной нагрузке.

Как вы о них узнаете?

Один из важнейших источников информации о проблемах – error log file. Там вы найдете информацию о таких проблемах как падение сервера, ошибки соединений (если включена опция log_warnings=2), опциях, которые были указаны в конфигурационном файле, но не были включены из-за ошибки и ряде других. Правило работы с error log такое: если творится что-то непонятное, первым делом проверьте записи в error log. Error log file в том числе содержит информацию об ошибках сервера, которые недоступны клиентам. Поэтому желательно его держать всегда включенным даже если у вас включено логирование на уровне приложения.

Прием №25: если творится что-то непонятное, первым делом проверьте записи в error log.

Также вы можете настроить InnoDB Monitor, который будет писать всю информацию об InnoDB транзакцих в error log file.

Прием №26: насторйте InnoDB Monitor чтобы иметь в error log информацию о всех транзакциях с применением InnoDB таблиц.

Другой важный источник информации – slow query log. Он содержит все запросы, которые выполняются более чем long_query_time секунд. Дефолтное значение long_query_time – 10 секунд, но вы можете его изменить. Используйте slow query log для поиска медленных запросов. Также его можно настроить на запись всех запросов, не использующих индексы.

Прием №27: используйте slow query log чтобы выявить медленные запросы.

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

В этом случае нужно создать окружение, максимально приближенное к реальному, на тестовой машине.

В общем случае вам нужно запустить на отдельной, например, девелоперской машине, MySQL сервер той же версии, что и на рабочем сервере. Также вам нужно скопировать настройки из конфигурационного файла и загрузить данные. Проще всего сделать дамп при помощи команды mysqldump, но это не всегда удобно, так как может занять слишком много времени при большом объеме данных. MySQL поддерживает бинарную совместимость данных между платформами, поэтому можно просто скопировать файлы нужных таблиц. Смотрите приложение о способах backup и переноса данных между MySQL серверами.

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

Иногда нужно протестировать запрос на разных версиях. Об этом говорит сайт https://intellect.icu . Это может понадобиться, если вы столкнулись с багом в MySQL коде, который был исправлен позднее, и хотите проверить, будут ли остальные запросы вашего приложения равботать на этой новой версии. Это может быть не обязательно баг, но новая возможность.

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

Проще всего это сделать при помощи MySQL Sandbox. MySQL Sandbox – это кросс-платформенное приложение, написанное на Perl. Загрузить его можно с https://launchpad.net/mysql-sandbox

Загрузите *tar.gz пакет с нужной вам версией, затем установите MySQL Sandbox и запустите команду:

 

 

Замените mysql-5.4.2-beta-linux-x86_64-glibc23.tar.gz нужной вам версией.

Выше вы увидели, что sandbox server был инсталлирован в директории $HOME/sandboxes/msb_5_4_2. Также он был запущен:

 

 

Остановите сервер при помощи команды

 

 

Внесите необходимые изменения в конфигурационный файл, скопируйте данные, затем запустите сервер:

 

 

Песочница ( а sandbox переводится с английского как песочница) готова! Можете начинать тестировать.

Прием №28: используйте MySQL Sandbox, чтобы быстро и удобно оттестировать ваше приложение на нескольких версиях MySQL.

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

Чаще всего неверные результаты возникают при использовании предиката WHERE в совокупности с другими предикатами, такими как LIMIT, ORDER BY, GROUP BY, HAVING или же если в WHERE содержится несколько условий.

Вы можете минимизировать test case используя только часть данных.

Создайте таблицу с теми же полями, что и исходная:

 

 

Затем загрузите в эту таблицу только часть данных:

 

 

Далее работайте с таблицей test_problem до тех пор, пока не найдете причину неправильного поведения. Исправьте оригинальный запрос.

Тот же прием можно применять и для запросов, одновременно использующих несколько таблиц.

Прием №29: используйте часть данных при работе с запросами, которые возвращают неверные результаты на больших объемах.

 

Итоги.

В последней части мы рассмотрели приемы работы при тестировании проблем на рабочем сервере. Повторим их:

Прием №25: если творится что-то непонятное, первым делом проверьте записи в error log.

Прием №26: насторйте InnoDB Monitor чтобы иметь в error log информацию о всех транзакциях с применением InnoDB таблиц.

Прием №27: используйте slow query log чтобы выявить медленные запросы.

Прием №28: используйте MySQL Sandbox, чтобы быстро и удобно оттестировать ваше приложение на нескольких версиях MySQL.

Прием №29: используйте часть данных при работе с запросами, которые возвращают неверные результаты на больших объемах.

В заключение, эта статья об техники применяющиеся для отладки production приложений используемые sql подчеркивает важность того что вы тут, расширяете ваше сознание, знания, навыки и умения. Надеюсь, что теперь ты понял что такое техники применяющиеся для отладки production приложений используемые sql и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Методы выявления ошибок в SQL приложении

Из статьи мы узнали кратко, но содержательно про техники применяющиеся для отладки production приложений используемые sql