Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Pautov_MySQL_rukovodstvo_professionala.328368.rtf
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
713.1 Кб
Скачать

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%';.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]