WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 8. Планировщик событий Эта глава описывает планировщик событий MySQL, поддержка которого была добавлена в MySQL 5.1.6. 8.1. Обзор планировщика событий События MySQL представляют собой задачи, которые выполняются согласно плану. Следовательно, мы иногда обращаемся к ним как к планируемым событиям. Когда Вы создаете событие, Вы создаете именованный объект базы данных, содержащий одну или большее количество инструкций SQL, которые будут выполнены в одном или более регулярных интервалах, начиная и заканчивая в специфическую дату и время. Концептуально, это подобно идее Unix crontab (также известно как cron job) или Windows Task Scheduler. Регламентная работа этого типа также иногда известна как временный триггер, подразумевая, что она является объектом, который вызван приходом времени. В то время, как это по существу правильно, мы предпочитаем использовать термин "события", чтобы избежать беспорядка с понятием триггера. В то время как не имеется никакого средства в стандарте SQL для планирования события, есть прецеденты в других системах баз данных, и Вы можете обратить внимание на некоторые подобия между этими реализациями. События MySQL имеют следующие главные свойства и реквизиты: В MySQL 5.1.12 и позже событие уникально идентифицировано именем и схемой, к которой оно назначено. Ранее событие было также уникально для definer. Событие выполняет специфическое действие согласно плану. Это действие состоит из инструкции SQL, которая может быть составной. Синхронизация события может быть одноразовая или текущая. Одноразовое событие выполняется только один раз. Текущее событие повторяет действие в регулярном интервале, и план для события может быть назначено специфическое начало (день и время), конечный день и время, оба момента или ни один из них. По умолчанию событие начинается, как только создано, и продолжается неопределенно, пока оно не будет заблокировано или удалено. Пользователи могут создавать, изменять и удалять планируемые события, используя инструкции SQL, предназначенные для этих целей. Синтаксически недопустимое создание события и инструкции модификации терпят неудачу с соответствующим сообщением об ошибках. Пользователь может включать в действие события инструкции, которые требуют привилегий, которых пользователь фактически не имеет. Создание события или инструкция модификации пройдет нормально, но сбой вызовет действие события. Многие из реквизитов события могут быть установлены или изменяться, используя инструкции SQL. Эти реквизиты включают имя события, синхронизацию, постоянство (то есть, сохраняется ли событие после окончания плана), состояние (включено или заблокировано), действие, которое нужно выполнить, и схема, к которой событие назначено. definer события представляет собой пользователя, который создал событие, если событие не было изменено, тогда definer становится пользователь, который выдал последнюю инструкцию ALTER EVENT, производящую это событие. Событие может изменяться любым пользователем, имеющим привилегию EVENT на базе данных, для которой событие определено. До MySQL 5.1.12 только definer события или пользователь, имеющий привилегии на таблице mysql.event, мог изменять данное событие. Инструкция действия события может включать большинство инструкций SQL, разрешенных внутри сохраненных подпрограмм. События выполнены специальным потоком планировщика событий. При выполнении поток планировщика события и текущее состояние могут быть замечены пользователями, имеющими привилегию SUPER в выводе SHOW PROCESSLIST, как показано ниже. Глобальная переменная event_scheduler определяет, включен ли планировщику событий на сервере. При запуске MySQL 5.1.12 это имеет одно из этих 3 значений, которые воздействуют на планируемые события, как описано здесь: OFF: Планировщик остановлен. Поток планировщика события не выполняется, не показывается в выводе SHOW PROCESSLIST и никакие планируемые события не выполнены. OFF является значением по умолчанию для event_scheduler. Когда планировщик событий остановлен (event_scheduler установлено в OFF), он может быть запущен, устанавливая значение event_scheduler в ON. ON: Планировщик работает: поток планировщика событий выполняется сам и выполняет все планируемые события. Поток планировщика событий перечислен в выводе SHOW PROCESSLIST как фоновый процесс, и его состояние представляется как показано здесь: mysql> SHOW PROCESSLIST \G *************************** 1. row *************************** Id: 1 User: root Host: localhost db: NULL Command: Query Time: 0 State: NULL Info: show processlist *************************** 2. row *************************** Id: 2 User: event_scheduler Host: localhost db: NULL Command: Daemon Time: 3 State: Waiting for next activation Info: NULL 2 rows in set (0.00 sec) DISABLED: значение делает планировщик событий неактивным. Когда планировщик событий заблокирован, его поток не выполняется (и не появляется в выводе SHOW PROCESSLIST). Когда сервер запущен, event_scheduler может переключаться ON и OFF (используя SET). Также возможно использовать 0 для OFF и 1 для ON при установке этой переменной. Таким образом, любая из следующих 4 инструкций может использоваться в клиенте mysql, чтобы включить планировщик событий: SET GLOBAL event_scheduler = ON; SET @@global.event_scheduler = ON; SET GLOBAL event_scheduler = 1; SET @@global.event_scheduler = 1; Точно так же любая из этих 4 инструкций может использоваться, чтобы выключить планировщик событий: SET GLOBAL event_scheduler = OFF; SET @@global.event_scheduler = OFF; SET GLOBAL event_scheduler = 0; SET @@global.event_scheduler = 0; Хотя ON и OFF имеет числовые эквиваленты, значение, отображаемое для event_scheduler вызовом SELECT или SHOW VARIABLES всегда OFF, ON или DISABLED. Значение DISABLED не имеет никакого числового эквивалента. По этой причине ON и OFF обычно предпочитаются 1 и 0 при установке этой переменной. Обратите внимание, что делая попытку устанавливать event_scheduler без того, чтобы определять ее как глобальную переменную, вы получите ошибку: mysql< SET @@event_scheduler = OFF; ERROR 1229 (HY000): Variable 'event_scheduler' is a GLOBAL variable and should be set with SET GLOBAL Важно: нельзя включать или выключать планировщик, если сервер работает. То есть, Вы можете изменять значение event_scheduler на DISABLED или с DISABLED на одно из других разрешенных значений для этой опции только, когда сервер остановлен. Попытка это сделать, когда он выполняется, вызовет сбой с ошибкой. Чтобы отключить планировщик событий, используйте один из следующих двух методов: Как опция командной строки при старте сервера: --event-scheduler=DISABLED В файле конфигурации (my.cnf, или my.ini в Windows) включите строку (например, в раздел [mysqld]): event_scheduler=DISABLED Чтобы включить планировщик, перезапустите сервер без параметра --event-scheduler=DISABLED или после удаления (или комментирования) строки, содержащей event_scheduler=DISABLED в файле конфигурации. В качестве альтернативы Вы можете использовать ON (или 1), либо OFF (или 0) вместо значения DISABLED при старте сервера. Обратите внимание: Вы можете выдавать инструкции манипулирования событиями, когда event_scheduler установлен в DISABLED. Никакие предупреждения или ошибки не будут сгенерированы в таких случаях (если инструкции самостоятельно допустимы). Однако, планируемые события не могут выполняться, пока эта переменная не установлена в ON (или 1). Как только это было выполнено, поток планировщика выполняет все события, чьи планирующие условия удовлетворены. В MySQL 5.1.11 event_scheduler вела себя следующим образом: эта переменная могла брать одно из значений 0 (или OFF), 1 (или ON) или 2. Установка в 0 отключала планировщик. Установка в 1 запускала планировщик и выполняла планируемые события. В этом состоянии поток планировщика события, казалось, бездействовала когда просматривалась с SHOW PROCESSLIST. Когда event_scheduler была установлена в 2 (что и было значением по умолчанию), планировщик событий был приостановлен: поток планировщика событий выполнялся и мог быть найден в выводе SHOW PROCESSLIST (где в столбце State отображалось Suspended), но не выполнялись никакие планируемые события. Значение event_scheduler могло быть изменено только между 1 (или ON) и 2 во время работы сервера. Установка в OFF или изменение из OFF) требовала рестарта сервера. До MySQL 5.1.11 event_scheduler мог брать только одно из 2 значений: 0|OFF (по умолчанию) или 1|ON без перезапуска сервера. MySQL 5.1.6 и позже обеспечивает таблицу EVENTS в базе данных INFORMATION_SCHEMA. Эта таблица может делать запрос к информации относительно планируемых событий, которые были определены на сервере. 8.2. Синтаксис планировщика событий MySQL 5.1.6 и позже обеспечивает несколько инструкций SQL для работы с планируемыми событиями: Новые события определены, используя инструкцию CREATE EVENT. Определение существующего события может быть изменено посредством инструкции ALTER EVENT. Когда планируемое событие больше не требуется, оно может быть удалено с сервера использованием инструкции DROP EVENT. Сохраняется ли событие после конца плана, также зависит от предложения ON COMPLETION, если оно имеется. Событие может быть удалено любым пользователем, имеющим привилегию EVENT для базы данных, в которой событие определено. До MySQL 5.12 пользователь, который не создавал это событие, требовал привилегий на таблице mysql.event. 8.2.1. Синтаксис CREATE EVENT CREATE EVENT [IF NOT EXISTS] event_name ON SCHEDULE schedule [ON COMPLETION [NOT] PRESERVE] [ENABLE | DISABLE] [COMMENT 'comment'] DO sql_statement; schedule: AT timestamp [+ INTERVAL interval] | EVERY interval [STARTS timestamp] [ENDS timestamp] interval: quantity {YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE | WEEK | SECOND | YEAR_MONTH | DAY_HOUR | DAY_MINUTE | DAY_SECOND | HOUR_MINUTE | HOUR_SECOND | MINUTE_SECOND} Эта инструкция создает и планирует новое событие. Минимальные требования для допустимой инструкции CREATE EVENT следующие: Ключевые слова CREATE EVENT плюс имя события, которое уникально идентифицирует событие в текущей схеме. До MySQL 5.1.12 имя события должно было быть уникальным только среди событий, созданных тем же самым пользователем в этой базе данных. Предложение ON SCHEDULE, которое определяет, когда и как часто событие выполняется. Предложение DO, которое содержит инструкцию SQL, которая будет выполнена событием. Это пример минимальной инструкции CREATE EVENT myevent ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR DO UPDATE myschema.mytable SET mycol = mycol + 1; Предыдущая инструкция создает событие myevent. Это событие выполняется один раз в час после создания, выполняя инструкцию SQL, которая увеличивает значение столбца mycol таблицы myschema.mytable на 1. Имя event_name должно быть допустимым идентификатором MySQL с максимальной длиной в 64 символа. Это может быть разграничено, используя обратные импульсы сигнала времени, и может быть квалифицировано с именем схемы базы данных. Событие связано с пользователем MySQL (definer) и схемой, так что имя должно быть уникальным среди имен событий внутри этой схемы. Вообще, правила, управляющие именами событий, такие же, как для имен сохраненных подпрограмм, поскольку события по сути и являются такими подпрограммами, только особыми. Если никакая схема не обозначена как часть event_name, то принята заданная по умолчанию схема. Definer всегда текущий пользователь MySQL. До MySQL 5.1.12 было возможно для двух различных пользователей создать различные события, имеющие то же самое имя в той же самой схеме базы данных. Обратите внимание: MySQL использует сравнения без учета регистра при прверке уникальности имен события. Это означает, что, например, Вы не можете иметь два события events named myevent и MyEvent в той же самой схеме базы данных. Функция IF NOT EXISTS с инструкцией CREATE EVENT работает полностью аналогично варианту с CREATE TABLE: если событие event_name уже существует в той же самой схеме, никаких действий не предпринимается, и никакой ошибки не будет. Однако, предупреждение будет сгенерировано. Предложение ON SCHEDULE определяет, когда, как часто и как долго sql_statement определено для повторения события. Это предложение берет одну из двух форм: AT timestamp используется для одноразового события. Это определяет, что событие выполняется только однократно, а именно в дату и время, заданные как timestamp, причем надо указать вместе дату и время, либо задать выражение, которое раскрывается в однозначный тип datetime. Вы можете использовать значение, которое имеет тип DATETIME или TIMESTAMP для этой цели. Указанный timestamp должен также быть в будущем. Вы не можете планировать событие, которое должно было произойти в прошлом. Попытка это сделать приведет к ошибке: mysql> SELECT NOW(); +---------------------+ | NOW() | +---------------------+ | 2006-02-10 23:59:01 | +---------------------+ 1 row in set (0.04 sec) mysql> CREATE EVENT e_totals -> ON SCHEDULE AT '2006-02-10 23:59:00' -> DO INSERT INTO test.totals VALUES (NOW()); ERROR 1522 (HY000): Activation (AT) time is in the past Инструкции CREATE EVENT, которые являются самостоятельно недопустимыми по любой причине, также завершаются ошибкой. Вы можете использовать CURRENT_TIMESTAMP, чтобы определить текущую дату и время. В таком случае событие действует, как только оно будет полностью создано. Чтобы создавать событие, которое происходит в некоторой отметке в будущем относительно текущей даты и времени Вы можете использовать факультативное предложение + INTERVAL interval. Часть interval состоит из двух кусков: количества и модуля времени, и следует тем же самым правилам синтаксиса, которые управляют интервалами, используемыми в функции DATE_ADD(). Ключевые слова модулей также те же самые за исключением того, что Вы не можете использовать любые модули, включающие микросекунды, при определении события. Вы можете также объединять интервалы. Например, AT CURRENT_TIMESTAMP + INTERVAL 3 WEEK + INTERVAL 2 DAY эквивалентно "три недели и два дня с этого времени". Каждая часть такого предложения должна начинаться с + INTERVAL. Для действий, которые должны быть повторены в регулярном интервале, Вы можете использовать предложение EVERY. Ключевое слово EVERY сопровождается интервалом, как описано выше. (+ INTERVAL не используется с EVERY). Например, EVERY 6 WEEK означает "каждые шесть недель". Невозможно объединить предложения + INTERVAL в одиночном предложении EVERY. Однако, Вы можете использовать те же самые сложные модули времени, позволенные в + INTERVAL. Например, каждые две минуты и десять секунд можно задать как EVERY '2:10' MINUTE_SECOND. Предложение EVERY может также содержать факультативное предложение STARTS. Оно сопровождается значением timestamp, которое указывает, когда действие должно начать повторяться, и может также использовать + INTERVAL interval, чтобы определить количество времени с этого момента. Например, EVERY 3 MONTH STARTS CURRENT_TIMESTAMP + 1 WEEK означает "каждые три месяца, начиная спустя одну неделю с этого времени". Точно так же Вы можете выражать "каждые две недели, начиная через шесть часов и пятнадцать минут с этого времени" с помощью EVERY 2 WEEK STARTS CURRENT_TIMESTAMP + '6:15' HOUR_MINUTE. Не определение STARTS аналогично STARTS CURRENT_TIMESTAMP, то есть действие, определенное для события, начинает повторяться немедленно после создания события. Предложение EVERY может также содержать факультативное предложение ENDS. Это ключевое слово сопровождается значением timestamp, которое сообщает MySQL, когда событие должно перестать повторяться. Вы можете также использовать + INTERVAL interval с ENDS. Например: EVERY 12 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 30 MINUTE ENDS CURRENT_TIMESTAMP + INTERVAL 4 WEEK означает "каждые двенадцать часов, начиная спустя тридцать минут с этого времени, и заканчивая через четыре недели тоже с этого времени". Не использование ENDS означает, что событие продолжает выполняться неопределенно долго. ENDS поддерживает тот же самый синтаксис для сложных модулей времени, что и STARTS. Вы можете использовать STARTS, ENDS вместе или порознь (либо вовсе не использовать их) в предложении EVERY. Обратите внимание: где STARTS или ENDS заданы как значение datetime, используется местное время на сервере. Однако, значения для обоих значений в настоящее время сообщены, используя Universal Time в таблицах INFORMATION_SCHEMA.EVENTS и mysql.event, также как в выводе SHOW EVENTS. Это неправильное поведение, и Ваша прикладная программа не должна полагаься на это, поскольку ситуация изменится (Глюк #16420 ). Предложение ON SCHEDULE может использовать выражения, включающие встроенные функции MySQL и переменные пользователя, чтобы получить любое значение timestamp или interval. Вы не можете использовать сохраненные подпрограммы или определяемые пользователем функции в таких выражениях, и при этом Вы не можете использовать любые ссылки на таблицы, однако, Вы можете SELECT FROM DUAL. Это истинно для инструкций CREATE EVENT и ALTER EVENT. Начиная с MySQL 5.1.13, ссылки на сохраненные подпрограммы, определяемые пользователем функции и таблицы в таких случаях специально отвергнуты и вызывают сбой с ошибкой (Глюк #22830). Обычно, как только событие истекло, оно немедленно уничтожается. Вы можете отменять это поведение, определяя ON COMPLETION PRESERVE. Использование ON COMPLETION NOT PRESERVE просто делает заданное по умолчанию поведение явным. Вы можете создавать событие и сохранить его неактивным для дальнейшего неспешного потребления, используя ключевое слово DISABLE. В качестве альтернативы Вы можете использовать ENABLE, чтобы сделать явным заданное по умолчанию состояние, которое является активным. Это наиболее полезно вместе с ALTER EVENT. Вы можете обеспечивать комментарий для события, используя предложение COMMENT. Здесь comment может быть любой строкой до 64 символов, которые Вы желаете использовать для описания события. Текст комментария, являющийся строковым литералом, должен быть окружен кавычками. Предложение DO определяет действие, которое несет событие, и состоит из инструкции SQL. Почти любая допустимая инструкция MySQL, которая может использоваться в сохраненной подпрограмме, может также использоваться как инструкция действия для планируемого события. Например, следующее событие e_hourly удаляет все строки из таблицы sessions раз в час, если только эта таблица часть схемы site_activity: CREATE EVENT e_hourly ON SCHEDULE EVERY 1 HOUR COMMENT 'Clears out sessions table each hour.' DO DELETE FROM site_activity.sessions; Инструкция CREATE EVENT, которая содержит инструкцию ALTER EVENT в предложении DO, появляется, однако, когда сервер пытается выполнить возникающее в результате планируемое событие, получается сбой выполнения с ошибкой. Обратите внимание: инструкции SHOW и SELECT, которые просто возвращают набор результатов, не имеют никакого эффекта, когда используются в событии, вывод из них не будет послан MySQL Monitor. Однако, Вы можете использовать инструкции типа SELECT INTO и INSERT ... SELECT, которые сохраняют результат. Любая ссылка в предложении DO к таблице в другой схеме базы данных должна быть квалифицирована с именем схемы, в которой таблица находится. В MySQL 5.1.6 все таблицы, вызванные в предложениях DO событий должны были включать ссылку на базу данных. Как и в случае с сохраненными подпрограммами, Вы можете использовать много инструкций в предложении DO заключением их в слова BEGIN и END, как показано здесь: DELIMITER | CREATE EVENT e_daily ON SCHEDULE EVERY 1 DAY COMMENT 'Saves total number of sessions then clears the table each day.' DO BEGIN INSERT INTO site_activity.totals (when, total) SELECT CURRENT_TIMESTAMP, COUNT(*) FROM site_activity.sessions; DELETE FROM site_activity.sessions; END | DELIMITER ; Обратите внимание на использование инструкции DELIMITER, чтобы изменить операторный разделитель, как с сохраненными подпрограммами. Более сложные составные инструкции, типа тех, что используюся в сохраненных подпрограммах, возможны в событии. Этот пример использует локальные переменные, драйвер ошибки и конструкцию управления потоком данных: DELIMITER | CREATE EVENT e ON SCHEDULE EVERY 5 SECOND DO BEGIN DECLARE v INTEGER; DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN END; SET v = 0; WHILE v < 5 DO INSERT INTO t1 VALUES (0); UPDATE t2 SET s1 = s1 + 1; SET v = v + 1; END WHILE; END | DELIMITER ; Не имеется никакого способа передать параметры непосредственно событию, однако, возможно вызвать сохраненную подпрограмму с параметрами: CREATE EVENT e_call_myproc ON SCHEDULE AT CURRENT_TIMESTAMP + 1 DAY DO CALL myproc(5, 27); Кроме того, если definer события имеет привилегию SUPER, то событие может читать и записывать глобальные переменные. Так как предоставление этой привилегии влечет за собой потенциал для неправильного обращения, критическая осторожность должна быть проявлена. Вообще, любые инструкции, которые являются допустимыми в сохраненных подпрограммах, могут использоваться для инструкций действия, выполненных событиями. Вы можете создавать событие как часть сохраненной подпрограммы, но событие не может быть создано другим событием. 8.2.2. Синтаксис ALTER EVENT ALTER EVENT event_name [ON SCHEDULE schedule] [RENAME TO new_event_name] [ON COMPLETION [NOT] PRESERVE] [ENABLE | DISABLE] [COMMENT 'comment'] [DO sql_statement] Инструкция ALTER EVENT используется, чтобы изменить одну или большее количество характеристик существующего события. Синтаксис для каждого из предложений ON SCHEDULE, ON COMPLETION, COMMENT, ENABLE / DISABLE и DO точно такой же, как когда они используются с CREATE EVENT. Начиная с MySQL 5.1.12, любой пользователь может изменять событие, определенное в базе данных, для которой этот пользователь имеет привилегию EVENT. Когда пользователь выполняет успешную инструкцию ALTER EVENT он становится definer для произведенного события. В MySQL 5.1.11 и ранее событие могло быть изменено только definer или пользователем, имеющим привилегию SUPER. ALTER EVENT работает только с существующим событием: mysql> ALTER EVENT no_such_event > ON SCHEDULE > EVERY '2:3' DAY_HOUR; ERROR 1517 (HY000): Unknown event 'no_such_event' В каждом из следующих примеров считайте, что событие myevent определено, как показано здесь: CREATE EVENT myevent ON SCHEDULE EVERY 6 HOUR COMMENT 'A sample comment.' DO UPDATE myschema.mytable SET mycol = mycol + 1; Следующая инструкция изменяет план для myevent с одного раза каждые шесть часов (запуск немедленно) на один раз каждые двенадцать часов, запуская четыре часа со времени выполнения инструкции: ALTER EVENT myevent ON SCHEDULE EVERY 12 HOUR STARTS CURRENT_TIMESTAMP + 4 HOUR; Чтобы отключить myevent используйте эту инструкцию ALTER EVENT: ALTER EVENT myevent DISABLE; Предложение ON SCHEDULE может использовать выражения, включающие встроенные функции MySQL и переменные пользователя, чтобы получить любой timestamp или interval. Вы не можете использовать сохраненные подпрограммы или определяемые пользователем функции в таких выражениях, и при этом Вы не можете использовать любые ссылки на таблицы, однако, Вы можете использовать SELECT FROM DUAL. Инструкция ALTER EVENT, которая содержит другую инструкцию ALTER EVENT в предложении DO, допустима. Однако, когда сервер пытается выполнять возникающее в результате планируемое событие, произойдет сбой с ошибкой. Возможно изменить много характеристик события в одиночной инструкции. Этот пример изменяет инструкцию SQL, выполненную myevent, а также план для события: ALTER TABLE myevent ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 DAY DO TRUNCATE TABLE myschema.mytable; Чтобы переименовывать событие, используйте предложение RENAME TO инструкции ALTER EVENT, как показано здесь: ALTER EVENT myevent RENAME TO yourevent; Предыдущая инструкция переименовывает событие myevent в yourevent. Примечание : не имеется никакой инструкции RENAME EVENT. Вы можете также переместить событие в другую схему, используя ALTER EVENT ... RENAME TO ... и запись в формате schema_name.table_name, как показано здесь: ALTER EVENT oldschema.myevent RENAME TO newschema.myevent; Чтобы выполнять предыдущую инструкцию, пользователь, выполняющий это, должен иметь привилегию EVENT на схемах oldschema и newschema базы данных. Необходимо включить только те параметры в инструкцию ALTER EVENT, которые соответствуют характеристикам, которые Вы фактически желаете изменить, параметры, которые опущены, сохраняют их существующие значения. Это включает любые значения по умолчанию для CREATE EVENT, например, ENABLE. 8.2.3. Синтаксис DROP EVENT DROP EVENT [IF EXISTS] event_name Эта инструкция удаляет событие event_name. Событие немедленно прекращает активность и будет удалено полностью с сервера. Если событие не существует, произойдет ошибка ERROR 1517 (HY000): Unknown event 'event_name'. Вы можете поменять это и заставить инструкцию провалиться тихо, используя опцию IF EXISTS. Начиная с MySQL 5.1.12, событие может быть удалено любым пользователем, имеющим привилегию EVENT на схеме базы данных, событие в которой должно быть удалено. В MySQL 5.1.11 и ранее событие могло быть удалено только definer или пользователем, имеющим привилегию SUPER. 8.3. Метаданные события Информация относительно событий может быть получена следующим образом: Запрос таблицы EVENTS базы данных INFORMATION_SCHEMA Использование инструкции SHOW EVENTS. Использование инструкции SHOW CREATE EVENT. Запись событий, выполненных на сервере, может читаться из файла регистрации ошибок MySQL. 8.4. Состояние планировщика событий Информация относительно состояния планировщика события для отладки и целей поиска неисправностей может быть получена следующим образом: В MySQL 5.1.11 версиях -debug Вы можете использовать инструкцию SHOW SCHEDULER STATUS. Важно: эта инструкция была удалена в MySQL 5.1.12. Предполагается сделать инструкцию SQL, обеспечивающую подобные функциональные возможности, в будущем выпуске MySQL. Начиная с MySQL 5.1.12, информация состояния планировщика событий может быть получена, выполняя mysqladmin debug. После выполнения этой команды, файл регистрации ошибок содержит вывод в отношении планировщика событий, подобный тому, что показывается здесь: Events status: LLA = Last Locked AtLUA = Last Unlocked At WOC = Waiting On ConditionDL = Data Locked Event scheduler status: State: INITIALIZED Thread id: 0 LLA: init_scheduler:313 LUA: init_scheduler:318 WOC: NO Workers: 0 Executed : 0 Data locked: NO Event queue status: Element count : 1 Data locked : NO Attempting lock : NO LLA : init_queue:148 LUA : init_queue:168 WOC : NO Next activation : 0000-00-00 00:00:00 8.5. Планировщик событий и привилегии MySQL Чтобы включить или отключить выполнение планируемых событий, необходимо установить значение глобальной переменной event_scheduler. Это требует привилегии SUPER. MySQL 5.1.6 представляет привилегию EVENT, управляя созданием, модификацией и стиранием событий. Эта привилегия может быть подарена, используя GRANT. Например, эта инструкция GRANT предоставляет привилегию EVENT для схемы myschema на пользователя jon@ghidora: GRANT EVENT ON myschema.* TO jon@ghidora; Чтобы предоставлять этому пользователю привилегию EVENT на всех схемах, требуется следующая инструкция: GRANT EVENT ON *.* TO jon@ghidora; Привилегия EVENT имеет контекст уровня схемы. Следовательно, попытка предоставлять ее на одиночной таблице приводит к ошибке, как показано здесь: mysql> GRANT EVENT ON myschema.mytable TO jon@ghidora; ERROR 1144 (42000): Illegal GRANT/REVOKE command; please consult the manual to see which privileges can be used Важно понять, что событие выполнено с привилегиями definer, и что оно не может выполнять любые действия, для которых definer не имеет необходимых привилегий. Например, предположим, что jon@ghidora имеет привилегию EVENT для myschema. Предположим также, что этот пользователь имеет привилегию SELECT для myschema, но никаких других привилегий для этой схемы он не имеет. Возможно для jon@ghidora создать новое событие типа этого: CREATE EVENT e_store_ts ON SCHEDULE EVERY 10 SECOND DO INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP()); Пользователь ждет в течение минуты или более, а затем выполняет запрос SELECT * FROM mytable;, ожидая, что увидит несколько новых строк в таблице. Вместо этого он находит, что таблица пуста: так как он не имеет привилегии INSERT для рассматриваемой таблицы, событие не имеет никакого эффекта. Если Вы осматриваете файл регистрации ошибок MySQL (hostname.err), Вы можете видеть, что событие-то выполняется, но действие это вызывает сбой, как обозначено RetCode=0: 060209 22:39:44 [Note] EVEX EXECUTING event newdb.e [EXPR:10] 060209 22:39:44 [Note] EVEX EXECUTED event newdb.e[EXPR:10]. RetCode=0 060209 22:39:54 [Note] EVEX EXECUTING event newdb.e [EXPR:10] 060209 22:39:54 [Note] EVEX EXECUTED event newdb.e[EXPR:10]. RetCode=0 060209 22:40:04 [Note] EVEX EXECUTING event newdb.e [EXPR:10] 060209 22:40:04 [Note] EVEX EXECUTED event newdb.e[EXPR:10]. RetCode=0 Так как этот пользователь, очень вероятно, не имеет доступа к файлу регистрации ошибок, он может проверять, является ли инструкция действия события допустимой, выполняя ее непосредственно: mysql> INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP()); ERROR 1142 (42000): INSERT command denied to user 'jon'@'ghidora' for table 'mytable' Проверка таблицы INFORMATION_SCHEMA.EVENTS показывает, что e_store_ts существует и включен, но столбец LAST_EXECUTED записан NULL: mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS > WHERE EVENT_NAME='e_store_ts' > AND EVENT_SCHEMA='myschema'\G *************************** 1. row *************************** EVENT_CATALOG: NULL EVENT_SCHEMA: myschema EVENT_NAME: e_store_ts DEFINER: jon@ghidora EVENT_BODY: SQL EVENT_DEFINITION: INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP()) EVENT_TYPE: RECURRING EXECUTE_AT: NULL INTERVAL_VALUE: 5 INTERVAL_FIELD: INTERVAL_SECOND SQL_MODE: NULL STARTS: 0000-00-00 00:00:00 ENDS: 0000-00-00 00:00:00 STATUS: ENABLED ON_COMPLETION: NOT PRESERVE CREATED: 2006-02-09 22:36:06 LAST_ALTERED: 2006-02-09 22:36:06 LAST_EXECUTED: NULL EVENT_COMMENT: 1 row in set (0.00 sec) (Обратите внимание: до MySQL 5.1.12 не было столбца EVENT_DEFINITION, по причине чего EVENT_BODY содержал инструкцию SQL или инструкции, которые будут выполнены. Чтобы отменить привилегию EVENT, используйте инструкцию REVOKE. В этом примере привилегия EVENT на схеме myschema удалена из логина пользователя jon@ghidora: REVOKE EVENT ON myschema.* FROM jon@ghidora; Важно: отмена привилегии EVENT пользователя не удаляет и не отключает никакие события, которые, возможно, были им созданы! Например, предположим, что пользователю jon@ghidora предоставили привилегии EVENT и INSERT на схеме myschema. Этот пользователь затем создает следующее событие: CREATE EVENT e_insert ON SCHEDULE EVERY 7 SECOND DO INSERT INTO myschema.mytable; После того, как это событие было создано, root отменяет привилегию EVENT для jon@ghidora. Однако, e_insert продолжает выполняться, вставляя новую строку в mytable каждые семь секунд. Определения событий сохранены в таблице mysql.event, которая была добавлена в MySQL 5.1.6. Чтобы удвлить событие, созданное другим пользователем, MySQL-пользователь root (или другой пользователь с необходимыми привилегиями) может удалять строки из этой таблицы. Например, чтобы удалить событие e_insert, показанное выше, root может использовать следующую инструкцию: DELETE FROM mysql.event WHERE db = 'myschema' AND definer = 'jon@ghidora' AND name = 'e_insert'; Очень важно соответствовать имени события, имени схемы базы данных и логину пользователя при удалении строк из таблицы mysql.event. Это потому, что тот же самый пользователь может создавать различные события с тем же самым именем в различных схемах. Обратите внимание: пространство имен для планируемых событий изменено в MySQL 5.1.12. До этого MySQL различные пользователи могли создавать различные события, имеющие то же самое имя в той же самой базе данных, в MySQL 5.1.12 и позже это не так. При обновлении на MySQL 5.1.12 или позже с MySQL 5.1.11 или ранее до выполнения обновления чрезвычайно важно удостовериться, что никакие события в той же самой базе данных не используют совместно то же самое имя. Привилегии EVENT пользователей сохранены в столбцах Event_priv таблиц mysql.user и mysql.db. В обоих случаях этот столбец хранит одно из значений 'Y' или 'N' (по умолчанию 'N'). mysql.user.Event_priv установлен в 'Y' для данного пользователя только, если этот пользователь имеет глобальную привилегию EVENT (то есть, если привилегия была подарена, используя GRANT EVENT ON *.*). Для привилегии EVENT уровня схемы GRANT создает строку в mysql.db и устанавливает столбец Db той строки к имени схемы, столбец User к имени пользователя и Event_priv столбца в 'Y'. Никогда не должно быть никакой потребности управлять этими таблицами непосредственно, так как GRANT EVENT и инструкция REVOKE EVENT выполняют требуемые операции на них. MySQL 5.1.6 представляет пять переменных состояния, обеспечивающих подсчет связанных с событием операций (но не инструкций, выполненных событиями). Они: Com_create_event: число инструкций CREATE EVENT, выполненных начиная с последнего рестарта сервера. Com_alter_event: число инструкций ALTER EVENT, выполненных начиная с последнего рестарта сервера. Com_drop_event: число инструкций DROP EVENT, выполненных начиная с последнего рестарта сервера. Com_show_create_event: число инструкций SHOW CREATE EVENT, выполненных начиная с последнего рестарта сервера. Com_show_events: число инструкций SHOW EVENTS, выполненных начиная с последнего рестарта сервера. Вы можете просматривать текущие значения для все них в одно время, выполняя инструкцию SHOW STATUS LIKE '%event%';. 8.6. Ограничения планировщика событий Этот раздел вносит в список ограничения планирования событий в MySQL. В MySQL любая таблица, вызванная в инструкции действия события должна быть полностью квалифицирована именем схемы, в которой это происходит (то есть, как schema_name.table_name ). Событие не может быть создано, изменено или удалено триггером, сохраненной подпрограммой или другим событием. Событие также не может создавать, изменять или удалять триггеры или сохраненные подпрограммы (Глюк #16409 и Глюк #18896). Синхронизации события, использующие интервалы YEAR, QUARTER, MONTH и YEAR_MONTH отсчитываются в месяцах, любой другой интервал отсчитывается в секундах. Не имеется никакого способа заставить планируемые события, происходящие в тот же самый момент, выполниться в заданном порядке. Кроме того, из-за округления, характера прикладных программ и того факта, что ненулевой отрезок времени требуется, чтобы создать событие и сообщить о выполнении, события могут быть отсрочены на целых 1 или 2 секунды. Однако, время, показанное в столбце LAST_EXECUTED таблицы INFORMATION_SCHEMA.EVENTS или столбце last_executed таблицы mysql.event является всегда точным до секунды относительно момента, когда событие было фактически выполнено (Глюк #16522). Выполнение инструкций события не воздействует на серверные счетчики, вроде Com_select и Com_insert, которые отображаются командой SHOW STATUS. До MySQL 5.1.12 Вы не могли просматривать события другого пользователя в таблице INFORMATION_SCHEMA.EVENTS. Другими словами, любой запрос, сделанный к этой таблицы обрабатывался, как если бы содержал DEFINER = CURRENT_USER() в предложении WHERE. События не могут быть созданы с временем старта, которое находится в прошлом. События не поддерживают времена позже, чем конец Unix Epoch, это приблизительно конец 2037 года. До MySQL 5.1.8 обработка в планируемых событиях дат позже чем, эта вызывала сбой, теперь такие даты специально отвергнуты планировщиком событий (Глюк #16396). В MySQL 5.1.6 INFORMATION_SCHEMA.EVENTS показывает NULL в столбце SQL_MODE. Начиная с 5.1.7, SQL_MODE отображает то, что было в действительности, когда событие было создано. В MySQL 5.1.6 единственным способом удалять или менять событие, созданное пользователем, который не был definer этого события, было манипулирование таблицей системы mysql.event MySQL-пользователем root или другим пользователем с привилегиями на этой таблице. В MySQL 5.1.7 и выше DROP USER удаляет все события, для которых этот пользователь был definer, также DROP SCHEMA удаляет все события, связанные с удаляемой схемой. Как с сохраненными подпрограммами, события не перенесены к новой схеме инструкцией RENAME SCHEMA (или RENAME DATABASE). Начиная с MySQL 5.1.8, имена событий обработаны в нечувствительном к регистру режиме. Например, это означает, что Вы не можете иметь два события в той же самой базе данных с именами anEvent и AnEvent (а до MySQL 5.1.12 еще и с тем же самым definer). Важно: если Вы имеете события, созданные в MySQL 5.1.7 или ранее, которые назначены к той же самой базе данных, имеют тот же самый definer, и чьи имена отличаются только регистром символов, то Вы бы переименовали эти события, чтобы избежать проблем с обработкой учета регистра перед обновлением до MySQL 5.1.8 или позже. Ссылки на сохраненные подпрограммы, определяемые пользователем функции и таблицы в предложениях ON SCHEDULE инструкций CREATE EVENT и ALTER EVENT не обеспечиваются (Глюк #22830).

Поиск На сайте В Яндексе