Этот пост был изначально написан Роэлем Ван де Пааром
Поиск ошибок в MySQL — это не только увлекательно, но и то, чем я занимаюсь последние четыре года своей жизни.
Если вы хотите стать следующим Шейном Бестером (которого обычно считают самым опытным охотником за ошибками MySQL в мире) или просто хотите доказать, что можете перехитрить некоторых из лучших в мире программистов, поиск ошибок в MySQL — это навык, который больше не зарезервирован Инженеры QA вооружены множеством скриптов, дорогостоящим флеш-хранилищем и серверным оборудованием высшего класса. Конечно, для профессионалов этот путь еще впереди, но теперь любой, у кого есть средний ноутбук и стандартный жесткий диск, может получить массу удовольствия, пытаясь найти этот неуловимый сбой…
Если вы внимательно прочитаете этот пост, вы вполне можете найти хорошую (или две) ошибку, приводящую к сбою RQG (отличный инструмент для проверки качества базы данных). Linux будет предпочтительной тестирующей ОС, но если вы используете Windows в качестве основной ОС, я бы порекомендовал установить Virtual Box и запустить гостевую систему Linux на виртуальной машине подходящего размера (то есть большой). С точки зрения аббревиатуры «RQG» это означает «Генератор случайных запросов», также называемый «randgen».
Если вы не только после обнаружения какой-либо ошибки («поиска ошибок»), вы можете настроить грамматики RQG (файлы, которые определяют, какой тип SQL RQG выполняется), чтобы более или менее соответствовать вашей «проблемной области». Например, если вы всегда сталкиваетесь с ситуацией, когда сервер падает на запрос DELETE (как видно в конце журнала ошибок mysqld, например), вы захотите грамматику SQL, в которой определенно есть множество запросов DELETE. , Эти запросы должны быть тесно сопоставлены с фактическим запросом сбоя — сбой обычно происходит из-за абсолютно одинаковых или похожих операторов с одинаковыми условиями, условиями и т. Д.
Но, сделав шаг назад, чтобы начать работу с RQG, вы можете использовать сценарий setup_server.sh в percona-qa (подробнее о том, как получить percona-qa из Launchpad с помощью bazaar ниже), или вы можете использовать yum для ручной установки набор модулей, установленных на вашем компьютере с Linux:
$ sudo yum install kernel-devel wget patch сделать cmake automake autoconf libtool bzr gtest zlib-static \
gcc gcc-c ++ ncurses-devel libaio libaio-devel bison valgrind perl-DBD-mysql cpan zlib-devel \
bzip2 valgrind-devel sv devel openssl openssl-dev screen strace sysbench
(Обратите внимание, что я включил несколько дополнительных элементов, необходимых для Percona Server, и несколько таких удобных элементов, как, например, screen и sysbench. Обратите внимание, что вы можете изменить yum на apt-get, хотя для этого может потребоваться несколько изменений имени пакета — Ищите информацию в Интернете, если хотите использовать apt-get.)
После установки этих модулей вы можете:
1. Вытащите дерево из
панели запуска: ветка $ bzr lp: randgen
2. Убедитесь, что установлены зависимости (модули Perl и т. Д.). Следуйте:
https://github.com/RQG/RQG-Documentation/wiki/RandomQueryGeneratorQuickStart#wiki-Prerequisites
3. Проведите быстрый тест, чтобы убедиться, что RQG работает нормально:
https://github.com/RQG/RQG-Documentation/wiki/RandomQueryGeneratorQuickStart#wiki-Running_your_first_test
Если все это сработало, то поздравляю, теперь у вас работают простые RQG. Давайте теперь посмотрим, как структурирована RQG.
То, как вы можете думать о «выполнении» RQG в формате иерархического дерева, выглядит следующим образом: комбинаций. Pl запускает runall.pl, который запускает gentest.pl, который может запускать gendata.pl. Вам не нужно использовать комбинации. Pl (или даже runall.pl, как вы узнали бы, следуя приведенному выше примеру «запуска вашего первого теста»), т.е. mysqld можно запустить вручную, а затем можно использовать gentest.pl для тестирования. уже запущенный сервер), но runall.pl и, безусловно, комбинации.pl, несомненно, добавят больше силы нашему тестированию, как мы скоро увидим.
С точки зрения различных сценариев Perl (.pl), перечисленных в дереве, это:
— комбинации.pl, который генерирует много разных способов (читай «испытания»), в которых запускается RQG (используя runall.pl) с различными опциями для mysqld и т. д.
— runall.pl, который запускает / останавливает mysqld, выполняет различные высокоуровневые проверки и т. д. (другими словами; «базовый прогон RQG»)
— gentest.pl, который является компонентом-исполнителем (iow «фактический базовый тест RQG»)
— gendata.pl, который устанавливает данные (таблицы + данные)
Если вам известен инструмент тестирования производительности SysBench, вы можете сравнить gentest.pl с фактическим прогоном SysBench и gendata.pl с «подготовкой sysbench».
Чтобы попасть на настоящую территорию для поиска ошибок, мы будем использовать комбинации .pl, чтобы провести обширный случайный тест на сервере. Вы никогда не знаете, что вы можете найти. Небольшое предупреждение; прежде чем регистрировать свою недавно обнаруженную ошибку, убедитесь, что она не зарегистрирована на bugs.mysql.com (для ошибок MySQL Server) или на bugs.launchpad.net/percona-server (для ошибок Percona Server).
В этом примере мы будем тестировать Percona Server, поскольку используемая нами грамматика комбинации .pl (.cc) оптимизирована для Percona Server. Если вы хотите протестировать сервер MySQL, вы можете создать свои собственные грамматики или использовать одну из многих грамматик, доступных в RQG (хотя они еще не так много комбинаций. runall.pl грамматики однако). Для MySQL-совместимой грамматики комбинации.pl, которая тестирует оптимизатор, смотрите randgen / conf / optimizer / starfish.cc — грамматику, которую я разработал, работая над oracle.
Другой очень обширный набор грамматик, который можно использовать с Percona Server 5.6 (мы называем это нашей «базовой грамматикой», так как он тестирует многие функции, разработанные для Percona Server), можно найти в randgen / conf / percona_qa / 5.6 / * — отредактируйте, а затем используйте 5.6 .sh — сценарий запуска (в этом наборе WORKDIR и RQG_DIR) и 5.6.cc — файл комбинаций (в этих именах изменений пути для оптимизированного / отладочного и valgrind скомпилированного сервера в соответствии с вашей системой) для начала. Подробнее об этом ниже.
Более раннюю и более ограниченную версию этой базовой грамматики можно найти в вашем дереве рандгенов; перейдите к randgen / conf / percona_qa / и просмотрите файлы там. Эта более ограниченная базовая грамматика может использоваться для тестирования любой версии Percona Server, или вы можете следовать упомянутой выше и использовать 5.6 грамматику и тестировать Percona Server 5.6 — применяются те же основные шаги (подробно описаны ниже).
В каталоге percona_qa сценарий percona_qa.sh является сценарием запуска (например, 5.6.sh), файл percona_qa.yy содержит SQL (например, 5.6.yy и т. Д.), Файл .zz содержит определения данных и, наконец,. Файл cc — это комбинация комбинаций .pl, которая «комбинирует» различные опции из разных блоков. Combination.pl обладает большой силой поиска ошибок.
Примечание: вы можете узнать больше о том, как работают блоки опций: https://github.com/RQG/RQG-Documentation/wiki/RandomQueryGeneratorCombitions
Все, что вам нужно сделать, чтобы запустить исчерпывающий тестовый запуск, это отредактировать некоторые параметры (при условии, что на вашем тестовом компьютере уже установлен Percona Server) и запустить скрипт percona_qa.sh:
1. Отредактируйте сценарий «percona_qa.sh» и установите переменные WORKDIR и RQG_DIR (В отношении RQG_DIR сценарий обычно предполагает, что randgen хранится в WORKDIR, но вы можете изменить RQG_DIR так, чтобы он указывал на ваш путь загрузки randgen, например, RQG_DIR = / randgen).
2. Отредактируйте скрипт «percona_qa.cc» и укажите его местоположение вашего сервера в параметре –basedir = (то есть замените «/ Percona-Server» на «/ path_to_your_Percona_Server_installation».
На данный момент вы можете просто использовать стандартную установку Percona Server и удалить строку Valgrind прямо под той, которую мы только что отредактировали (используйте «dd» в vim), но как только вы станете немного более профессиональным, компилируете из исходного кода («build» ») Это способ пойти.
Причиной создания себя является то, что если вы используете отладочный скомпилированный сервер (т. Е. Выполните ./build/build-binary.sh –debug в исходной загрузке Percona Server) или инструментально скомпилированный сервер Valgrind (т. Е. Выполните ./build/build- Файл binary.sh –debug –valgrind в исходной загрузке Percona Server) вы найдете больше ошибок (сервер отладки содержит больше утверждений отладчика разработчика и т. д.).
Обратите внимание, что вы можете использовать «build_percona.sh» в проекте Percona-qa Launchpad (подробнее об этом ниже), чтобы быстро построить оптимизированный, отладочный и Valgrind сервер из исходного кода. build_mysql.sh делает то же самое для сервера MySQL.
3. Now you’re ready to go; execute ./percona_qa.sh and watch the screen carefully. You’ll likely immediately see some STATUS_ENVIRONMENT_FAILURE runs. This is quite common and means you have made a little error somewhere a long the way. Stop the run (ctrl+z, then kill -9 all relevant pids, then execute “fg”). Now edit the files as needed (check all the logs, starting with the failed trials ‘trial<no>.log’, etc.). Then start the run again. If your machine is used for testing only (i.e. no production programs running), you can use the following quick command to kill all relevant running mysqld, perl and Valgrind processes:
ps -ef | grep `whoami` | egrep "mysql|perl|valgrind" | grep -v "grep" | awk '{print $2}' | xargs sudo kill -9;
4. Once you’re run is going, leave it going for a few hours, or a few days (we regularly test with runs that go for 2-5 days or more), and then start checking logs (trial<nr>.log is the one you want to study first. Use “:$” in vim to jump to the end of the file, or “:1″ to jump back to the first line).
5. Once you get a bit more professional, use the percona-qa scripts (bzr branch lp:percona-qa) to quickly handle trials of interest. You may want to initially checkout rqg_results.sh, analyze_crash.sh, startup.sh, build_percona.sh, delete_single_trial.sh and keep_single_trial.sh – simply execute them without parameters to get an initial idea on how to use them. These scripts greatly reduce the efforts required when analyzing multiple trials.
6. Finally, for those of you needing the reduce long SQL testcases (from any source) quickly, see reducer.sh in randgen/util/reducer/reducer.sh – it’s a multi-threaded high-performance simplification script I developed whilst working at oracle. They kindly open sourced it some ago. You may then also want to checkout parse_general_log.pl in the percona-qa scripts listed in point 5 above. This script parses a general log created by mysqld (–general_log option) into a ready-to-use SQL trace.
If you happen to find a bug, share the joy! If you happen to run into issues, post your questions below so others who run into the same can find answers quickly. Also feel free to share any tips you find while playing around with this.
Enjoy!