MySQL RESET [целое число]
При проверке запросов, выполняемых в наших базах данных с использованием инструментов tcpdump и Maatkit, запрос номер один
RESET [int]
Выполнение этого оператора из командной строки MySQL приводит к ошибке, поскольку RESET должен принимать только параметры master, кеш запросов и slave.
Это утверждение не существует в нашей кодовой базе. Мы запускаем MySQL Enterprise Monitor, но указанный пользователь не является пользователем нашего мониторинга. Мы также используем инфраструктуру Zend с драйвером соединения mysqli, но не смогли найти никакого вызова для этого оператора.
Любые идеи относительно того, что это может быть?
3 ответа
Я подозреваю, что это mk-query-digest, неправильно интерпретирующий трафик TCP. Реконструкция трафика в качестве наблюдателя на обочине из-за неупорядоченных пакетов, пропущенных пакетов, повторных передач и т. Д. Никогда не была точной наукой. Когда в том, что видит mk-query-digest, есть много ошибок, иногда он может неверно интерпретировать трафик и обнаруживать вещи, которые могут не существовать.
Я бы предложил покопаться в выводе tcpdump вручную. Это утомительно, и протокол трудно декодировать вручную, но если вы выгружаете некоторые данные в файл и затем mk-query-digest его, mk-query-digest сообщит вам смещение байта в файле, где он находит образец запрос это распечатывает. Это должно позволить вам сузить один пакет, и с помощью документации по протоколу из руководства по внутренним компонентам MySQL вы сможете увидеть, действительно ли этот пакет является предполагаемым RESET. Я полагаю, что RESET, вероятно, связан с бинарным (подготовленным оператором) протоколом, если он реален; если это ложно, у меня нет догадок.
Вы используете tcpdump, так что вы можете сузить это, найдя, с какой рабочей станции (ей) это происходит. Если это все из них, значит что-то не так с вашими предположениями.
Если вы смотрите его с помощью tcpdump, вы должны знать, кто входит в систему, и порт источника. Первый дает вам возможность менять учетные данные по одному, пока проблемные запросы не изменят, какой логин они используют, и в этот момент вы будете знать их источник. Порт источника позволяет вам знать, равен ли ноль удаленный UID (если порт src <1024), а также дает вам возможность использовать netstat -ntp (*nix) или netstat -nto (Windows), чтобы определить, какой PID фактически генерирует запрос.