MySQL. CRON для MySQL

mastertron
9 років
0
Это больше как предложение!
На сколько я понял, MySQL находится на отдельном хосте?
Если так, то наверно было бы разумно сделать упор на хранимые процедуры, а периодическое обслуживание, как предусмотрено, событием MySQL. Однако при попытке создать event ничего не получилось, он создает события от пользователя user@мойIP, который естественно прав не имеет, а изменить владельца тоже нельзя.
Решением возможно будет подобная реализация:
- на хосте MySQL предоставить пользователю cron для операций с БД.
- при создании задания предоставить возможность настройки времени запуска и текстовую область для ввода SQL выражений.
Думаю это существенно расширит функционал и повысит производительность при сохранении политики безопасности.
Спасибо.
rudenko
9 років
0
Сейчас обойти это ограничение можно создав простенький PHP скрипт и выполнять в нем запросы в MySQL.
Начиная с версии 5.1 в MySQL есть EVENTS, которые работают именно так как Вы описали, в данный момент доступ к событиям EVENT MySQL мы не предоставляем, так как пользователи не совсем правильно их используют, а мы компания лояльная и не блокируем за это (блокируем за превышение нагрузки, но это так редко бывает, что нужно уложить для этого сервер). Поэтому нужно либо начать блокировать пользователей и предоставлять EVENTS или не предоставлять EVENTS :)
mastertron
9 років
0
EVENTSы понял, что не разрешены, зачем тада разрешили создавать их? Я потратил времени, пока понял, что они работать не будут :)
Согласен, нужно заботиться о хостинге и контролировать пользователей, уважаю политику " Запретить все, оставить только то, что можно".

По мне, так EVENTS еще как то сыроват, у меня даже на своем сервере многое не получается с его помощью ( не пойму, почему лыжи не едут... ).
Создавать скрипт на сайтовом хосте конечно можно, (и кстати, с него тоже можно грузануть ) но если БД находится на отдельном сервере, то все же лучшее решение, это запускать периодические задачи для MySQL с него самого.
А для пользователя сделать подобную сущестующей форму, с допустимыми значениями времени запуска, и область для SQL выражения?
В конечном итоге согласен с тем, что для большинства это совсем не актуально, т.к. практически все CMS ваабще ничего из БДхранимо-выполняющегося не используют, тупо запросы со своих скриптов. Размещение скриптов непосредственно в базе дает ощутимый выигрыш только при больших нагрузках, малой скважностью запросов.
Это я по старинке считаю каждый Кбт и предпочитю длиннее исходник, но меньше циклов и функций :)

По ходу вопрос: какие еще ограничения есть на БД ( заявленных в соглашении нет по поводу EVENTS )?
Меня интерисуют хранимые процедуры и функции. Ващета в них тоже нет "Защиты от дурака".

Спсибо за ответ.
rudenko
9 років
0
запускать периодические задачи для MySQL с него самого© mastertron

Все файлы MySQL принадлежат одному пользователю поэтому запуск скриптов на MySQL сервере очень сильно может повлечь за собой проблемы с безопасностью. Ведь единственная причина по которой Вы просите это, так это использовать LOAD DATA IN/OUT FILE, в остальных случаях не вижу смысла в выполнении запроса на SQL сервере.

Процедуры работают, триггеры работают, EVENTS кстати возможно тоже работают, если их создавать удается.
mastertron
9 років
0
Создавать - не проблема, только толку, если EVENT_шедулер не запущен
Access denied; you need the SUPER privilege FOR this operation ...

Может запустите? :)

По поводу безопасности запуска с крона - ну так не с рута ж запускать, а за кулисами вебморды формируется скрипт типа:

#/usr/local/......../mysql mybasa -h 91.206.200.228 -u vasya -ppetya < /путь к скрипту юзера


А там пусть ваяет юзер ...
По поводу выполнения запросов на MySQL сервере:
Переводя и объеденяя запросы в хранимые процедуры я добиваюсь максимально возможной производительности, много операций я могу выполнять без лишнего "гоняния" запросов между WEB сервером, MySQL сервером и браузером клиента, а это все время, трафик и нагрузка, пока генерится страница всп еременные висят в памяти, занимают драгоценное место, процесс висит и т.д..
Проверял сам разницу между тремя запросами с php скрипта к MySQL таблицам и одним обращением к хранимой процедуре с теми же тремя запросами. Разница ощущается на цикле в 100 и более раз - почти в 1,5 раза быстрее проходит запрос. А сколько таких запросов на генерацию одной страницы, к примеру, в joomla?

А вот на счет организации событий, тут конечно загвоздочка, если разрешать - то всем.
Я б очень хотел получить такую возможность. Запустите шедулер, а разрешение на создание EVENTSов зарубите! ( всем, а мне оставьте ).

Для чего мне это нужно? - да есть тут задачи. Ну каждую секунду нет, а вот */10 - самое оно. Если через сайт подключаются пользователи ( прим. 20-30 чел.), которым нужно своевременно сообщить инфу ( координация ) и сразу получить ответ, очень важно, чтоб инфа не пропала, а была обязательно доставлена и при том в строгом приоритете. Все пользователи регистрируют свое присутствие и статус, с их клиента опрос идет примерно */15 сек. ( тут уже хр. процедура тупо рулит ). Ну там еще есть заморочки, но фокус в том, что все выстроены в логическую цепочку, если на ком то разрыв - инфа повиснет как минимум на минуту при идеальном раскладе ( если кроном делать ). Предусмотрен статус "пропустить", но если у кого то просто пропала связь или батарея села - потерь не избежать. Данные все короткие, оперативная инфа держится в малых таблицах MEMORY.
Я запускался на своем сервере ( OpenBSD iPent4) и даже при EVENTs в 1 сек нагрузка составляла не более 0,15% на процесс mysqld.
Вобщем, если у Вас не получится, будем искать другой вариант.
Тема закрита.