Spec-Zone.ru › MySQL 9.2

27.5.6 Планировщик событий и привилегии MySQL

Для включения или отключения выполнения запланированных событий необходимо установить значение глобальной системной переменной event_scheduler. Это требует привилегий, достаточных для установки глобальных системных переменных. См. Раздел 7.1.9.1, «Привилегии системных переменных».

Привилегия 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

Важно понимать, что событие выполняется с привилегиями своего определяющего пользователя и не может выполнять какие-либо действия, для которых у определяющего пользователя нет необходимых привилегий. Например, предположим, что 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), вы увидите, что событие выполняется, но выполняемое им действие завершается ошибкой:

2013-09-24T12:41:31.261992Z 25 [ERROR] Event Scheduler:
[jon@ghidora][cookbook.e_store_ts] INSERT command denied to user
'jon'@'ghidora' for table 'mytable'
2013-09-24T12:41:31.262022Z 25 [Note] Event Scheduler:
[jon@ghidora].[myschema.e_store_ts] event execution failed.
2013-09-24T12:41:41.271796Z 26 [ERROR] Event Scheduler:
[jon@ghidora][cookbook.e_store_ts] INSERT command denied to user
'jon'@'ghidora' for table 'mytable'
2013-09-24T12:41:41.272761Z 26 [Note] Event Scheduler:
[jon@ghidora].[myschema.e_store_ts] event execution failed.

Поскольку у этого пользователя, скорее всего, нет доступа к журналу ошибок, можно проверить, является ли оператор действия события допустимым, выполнив его напрямую:

mysql> INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP());
ERROR 1142 (42000): INSERT command denied to user
'jon'@'ghidora' for table 'mytable'

Проверка таблицы схемы информации 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: 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)

Для отзыва привилегии 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 каждые семь секунд. То же самое будет верно, если root выпустит любое из этих утверждений:

  • DROP USER jon@ghidora;

  • RENAME USER jon@ghidora TO someotherguy@ghidora;

Вы можете убедиться в этом, изучив таблицу схемы информации EVENTS до и после выдачи оператора DROP USER или RENAME USER.

Определения событий хранятся в словаре данных. Чтобы удалить событие, созданное другой учетной записью пользователя, вы должны быть пользователем MySQL root или другим пользователем с необходимыми привилегиями.

Привилегии пользователей 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 выполняют необходимые операции над ними.

Пять переменных состояния предоставляют счётчики операций, связанных с событиями (но не с операторами, выполняемыми событиями; см. Раздел 27.9, «Ограничения на хранимые программы»). Это:

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

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-9.2-en/events-privileges.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API