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