Есть ли способ назначить период ожидания для запросов MySQL и ограничить их 60 секундами? Я знаю, что это возможно при использовании языка сценариев (например, PHP). Но можно ли настроить конфигурацию в MySQL напрямую, чтобы предотвратить отключение сервера долгими запросами (в моем случае обычно выбирает)?
ПРИМЕЧАНИЕ. При работе Mandriva база данных находится в MyISAM, и это только для запросов SELECT.
Простое решение - использовать Percona Toolkit's pt-kill вариант. Он имеет несколько опций и используется несколькими людьми.
Я бы рекомендовал использовать подчиненный сервер, но для этого требуются дополнительные ресурсы (сервер / экземпляр). При таком подходе ваш производственный сервер будет изолирован, и бизнесу не будет нанесен ущерб, даже если ваш босс напишет наихудший запрос.
На основании вашего ответа о типе запросов могу сказать следующее:
Если ваш босс выполняет только оператор выбора, вы можете рассмотреть возможность установки и запуска репликация mysql и предоставить ему доступ к подчиненному серверу базы данных. Таким образом, ваш производственный (главный) сервер не пострадает, если он наберет очень сложный и трудоемкий запрос.
Не по умолчанию, нет.
Однако команда Twitter выпустила свою работу над MySQL, который именно это реализует (от http://engineering.twitter.com/2012/04/mysql-at-twitter.html):
- Reduce unnecessary work through improved server-side statement timeout support. This allows the server to proactively cancel queries that run longer than a millisecond-granularity timeout.
Видеть https://github.com/twitter/mysql/wiki/Statement-Timeout и https://github.com/twitter/mysql.
Более тривиальное решение - запускать cronjob каждые X минут, который ищет запросы вашего босса и убивает их, если они выполняются дольше Y секунд.
Одно из решений, которое я обычно использую, если репликация / ведомые устройства не подходят, - это то, что вы пытаетесь избежать длительных запросов отчетов;
В этом случае ваш босс будет намного быстрее получать данные в новой таблице (ах) отчета. Вероятно, у вас уже есть хорошее решение, но оно все равно может быть полезно. :)