включить журнал запросов для одной базы данных

8

У меня есть много схем базы данных на сервере MySQL 5.6, теперь проблема в том, что я хочу перехватывать запросы только для одной схемы.

Я не могу включить журнал запросов для всего сервера, так как одна из моих схем сильно загружена, и это повлияет на сервер.

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

Я нашел график сравнения, который показывает влияние на транзакции / секунду, когда включен журнал запросов.

введите описание изображения здесь введите описание изображения здесь

Суяш Джайн
источник
Можете ли вы использовать медленный журнал запросов вместо этого? А затем проанализировать этот журнал с помощью pt-query-digest? Если нет, вы можете попробовать обработать вывод tcpdump с помощью pt-query-digest
jerichorivera

Ответы:

1

Интересный вопрос и +1. Меня это заинтересовало, потому что я вижу несколько вариантов использования этой функциональности.

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

То есть использовать переменную SQL_LOG_OFF, чтобы отключить ведение журнала для данного соединения. Идеальным решением было бы иметь переменную «SQL_LOG_ON», как это можно сделать в Oracle (эквивалент) - может быть, вы могли бы попробовать отключить выход из системы для всех, кроме интересующего вас соединения?

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

В зависимости от серьезности вашей проблемы, рабочего времени и нагрузки на сервер в указанное время, вы можете найти применение для pt-query-digest Percona, которое может помочь с анализом журнала. Небольшой комфорт, но, как обычно, PostgreSQL намного опережает MySQL ( 1 , 2 ).

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

Verace
источник
1

Если вы настолько близки к тому, чтобы перевернуться, что не можете включить общий журнал в ФАЙЛ, у вас проблемы хуже; они нуждаются в ремонте.

Я подозреваю, без какого-либо реального знания, что медленный журнал будет иметь аналогичное влияние, особенно с long_query_time = 0.

5.7 имеет функцию «переписать запрос». Там может быть использован какой-то трюк. (Но, опять же, есть некоторые накладные расходы, которые следует сравнить.)

Как долго вы хотите ловить запросы? Вы просто ищете источник одного непослушного действия? Или вы пытаетесь собрать запросы для создания реалистичного эталона для этой таблицы? Или что-то другое?

Репликация включена? Вы заинтересованы в чтениях? Или пишет? Или оба?

Сколько потоков активно одновременно? Тест, который вы показали, показал, что для 1 журнал имеет низкие накладные расходы. Это блокировка таблицы на MyISAM или CSV, которая убивает обработку для высокого параллелизма.

Ваш второй график показывает, что клиенты должны быть ограничены примерно 5-8 одновременными соединениями, иначе пропускная способность фактически снижается! Что было max_connectionsи Max_used_connectionsдля этого графика?

Рик Джеймс
источник
Привет, я хочу получать запросы в течение примерно 2 дней, и эти графики не связаны с моим сравнительным тестированием ... Я вставил их только для знания. Приложение, для которого я хочу запросы, потребляет мало ресурсов. Tcpdump не будет предоставлять статистику по времени.
Суяш Джайн