Der Event Scheduler: wiederkehrende Jobs direkt in MySQL

1. Was der MySQL Event Scheduler ist und wie man ihn aktiviert

Der Event Scheduler ist ein interner Thread in MySQL, der geplante Aufgaben, sogenannte Events, zu den festgelegten Zeitpunkten ausführt, ohne dass dafür ein externer Cron-Daemon oder eine Anwendung außerhalb der Datenbank nötig wäre. Die eigentliche Ausführungslogik jedes Events besteht aus einer beliebigen SQL-Anweisung oder einem zusammengesetzten Anweisungsblock, der wie eine gespeicherte Prozedur formuliert wird und mit den vollen Rechten des jeweiligen Definierers läuft.

Standardmäßig ist der Event Scheduler deaktiviert und muss über die Systemvariable event_scheduler aktiviert werden, wobei diese Einstellung für eine dauerhafte Wirkung über Neustarts hinweg zusätzlich in der Konfigurationsdatei hinterlegt werden sollte. Ohne aktivierten Scheduler existieren angelegte Events zwar weiterhin in den Metadaten, werden aber schlicht nie ausgeführt, was ein häufiger, leicht zu übersehender Stolperstein nach einem Server-Neuaufsetzen ist.

-- Scheduler zur Laufzeit aktivieren
SET GLOBAL event_scheduler = ON;

-- Dauerhaft in der Konfiguration verankern
-- /etc/mysql/mysql.conf.d/mysqld.cnf
-- [mysqld]
-- event_scheduler = ON

-- Status prüfen
SHOW VARIABLES LIKE 'event_scheduler';

2. CREATE-EVENT-Syntax und Scheduling-Optionen im Überblick

Ein wiederkehrendes Event wird über ON SCHEDULE EVERY mit einem Intervall in Sekunden, Minuten, Stunden, Tagen oder Wochen definiert, ergänzt um optionale Angaben für Start- und Endzeitpunkt über STARTS und ENDS. Für einmalige, zu einem festen Zeitpunkt auszuführende Aufgaben eignet sich stattdessen ON SCHEDULE AT mit einem konkreten Zeitstempel, was sich etwa für einmalige Migrations-Nachbereitungsjobs anbietet.

Die Klausel ON COMPLETION PRESERVE steuert, was nach der letzten Ausführung eines einmaligen Events geschieht: Ohne diese Klausel wird das Event nach Abschluss automatisch aus dem System entfernt, mit ihr bleibt die Definition erhalten und lässt sich über ALTER EVENT nachträglich untersuchen oder für einen erneuten Lauf reaktivieren.

-- Wiederkehrendes Event, stündlich ab sofort
CREATE EVENT ev_cleanup_expired_carts
ON SCHEDULE EVERY 1 HOUR
STARTS CURRENT_TIMESTAMP
COMMENT 'Entfernt abgelaufene Warenkorb-Reste aelter als 30 Tage'
DO
  DELETE FROM quote WHERE is_active = 0 AND updated_at < NOW() - INTERVAL 30 DAY;

-- Einmaliges Event zu einem festen Zeitpunkt, Definition danach erhalten
CREATE EVENT ev_migration_followup
ON SCHEDULE AT '2026-09-01 02:00:00'
ON COMPLETION PRESERVE
DO
  UPDATE catalog_product_flat_1 SET needs_reindex = 0;

3. Praxisbeispiel: ein wiederkehrender Cleanup-Job für Sessions und Logs

Ein naheliegender Einsatzzweck für Events sind reine Datenpflege-Aufgaben, die eng an eine einzelne Tabelle gebunden sind und keine externe Logik benötigen, etwa das Entfernen abgelaufener Sitzungsdaten oder alter Einträge aus Log-Tabellen wie report_event. Solche Aufgaben lassen sich vollständig innerhalb eines Events abbilden, ohne dass die Anwendung überhaupt Kenntnis von der Existenz dieses Jobs haben muss.

Wichtig für produktionstaugliche Cleanup-Events ist eine begrenzte Löschmenge pro Lauf, etwa über LIMIT in Kombination mit häufigerer Ausführung, statt einer einzelnen, potenziell sehr großen Löschoperation, die lange Sperren auf stark frequentierten Tabellen erzeugen und den regulären Anwendungsbetrieb spürbar beeinträchtigen würde.

4. Abgrenzung zu Magento-Cron und Anwendungs-Cron: wann DB-interne Events sinnvoll sind

Magento bringt mit der Tabelle cron_schedule und dem eigenen Cron-System bereits einen mächtigen, in die Anwendungslogik integrierten Scheduling-Mechanismus mit, der Zugriff auf das gesamte Objektsystem, Event-Observer und externe Dienste hat. Ein MySQL-Event kennt hingegen ausschließlich SQL und läuft vollständig außerhalb der PHP-Laufzeitumgebung, ohne Zugriff auf Magentos Cache-Invalidierung, Event-Dispatching oder externe APIs.

DB-interne Events sind deshalb dann sinnvoll, wenn eine Aufgabe rein datenbezogen ist, keinerlei Interaktion mit der Anwendungsschicht benötigt und selbst bei einem vollständig gestoppten Anwendungsserver zuverlässig weiterlaufen soll, etwa eine reine Aufräumaufgabe auf Datenbankebene. Sobald eine Aufgabe jedoch Magento-Objekte, Caches, E-Mail-Versand oder andere Anwendungsebenen berührt, gehört sie zwingend in Magentos eigenes Cron-System statt in einen MySQL-Event.

5. Wann Events NICHT die richtige Wahl sind

Komplexe Business-Logik, die mehrere Systeme koordiniert, etwa ein Job, der Bestelldaten aus MySQL liest, an ein externes ERP-System überträgt und anschließend den Bestellstatus in Magento aktualisiert, gehört eindeutig nicht in einen MySQL-Event. Ein Event kann weder HTTP-Aufrufe tätigen noch auf das Dateisystem zugreifen noch E-Mails versenden, und der Versuch, solche Logik mit Umwegen über sys_exec-artige Erweiterungen nachzubilden, öffnet gravierende Sicherheitslücken.

Ebenso ungeeignet sind Events für Aufgaben, die Retry-Logik, differenzierte Fehlerbehandlung oder eine Observability über Logging und Metriken benötigen, wie sie ein moderner Job-Queue-Mechanismus oder Magentos eigenes Cron-System bereits mitbringen. Ein MySQL-Event bietet dafür schlicht keine geeigneten Werkzeuge und sollte auf reine, in sich geschlossene Datenoperationen beschränkt bleiben.

6. Monitoring: information_schema.EVENTS und SHOW EVENTS

Der Status jedes definierten Events, einschließlich des Zeitpunkts der letzten Ausführung, lässt sich über die Sicht information_schema.EVENTS systematisch abfragen, was sich hervorragend für eine automatisierte Überwachung eignet. Die Spalte LAST_EXECUTED zeigt, wann ein Event zuletzt gelaufen ist, während die Spalte STATUS zwischen ENABLED, DISABLED und SLAVESIDE_DISABLED unterscheidet.

Ein sinnvoller Monitoring-Check vergleicht für jedes erwartete, wiederkehrende Event den Zeitpunkt der letzten Ausführung gegen das konfigurierte Intervall und schlägt Alarm, sobald ein Event deutlich länger nicht gelaufen ist als erwartet, unabhängig davon, ob die Ursache ein deaktiviertes Event, ein gestoppter Scheduler oder ein anderes Problem ist.

-- Übersicht aller definierten Events mit letztem Ausführungszeitpunkt
SELECT EVENT_NAME, STATUS, LAST_EXECUTED, INTERVAL_VALUE, INTERVAL_FIELD
FROM information_schema.EVENTS
WHERE EVENT_SCHEMA = 'magento';

-- Kurzform über SHOW EVENTS
SHOW EVENTS FROM magento;

7. Fehlerbehandlung: was bei einem fehlgeschlagenen Event passiert

Wirft die Anweisung innerhalb eines Events einen unbehandelten Fehler, etwa weil eine referenzierte Tabelle zwischenzeitlich umbenannt wurde, deaktiviert MySQL das betroffene Event automatisch, indem es den Status auf DISABLED setzt, und schreibt einen entsprechenden Eintrag in das Fehlerprotokoll. Es findet keinerlei automatischer Retry statt, und ohne aktives Monitoring bleibt ein derart deaktiviertes Event unter Umständen monatelang unbemerkt inaktiv.

Für robuste Events empfiehlt sich deshalb ein expliziter DECLARE ... HANDLER-Block innerhalb eines zusammengesetzten Anweisungsblocks, der erwartbare Fehler abfängt, in eine eigene Protokolltabelle schreibt und das Event dadurch aktiv am Leben hält, statt es MySQL-seitig automatisch deaktivieren zu lassen. Diese Protokolltabelle sollte wiederum Teil des regulären Monitorings sein, um fehlgeschlagene Einzelläufe zeitnah sichtbar zu machen.

8. Der Event Scheduler in Replikationsumgebungen und bei Failover

Event-Definitionen werden über die Replikation an alle Replicas repliziert, ausgeführt werden sie jedoch standardmäßig ausschließlich auf dem Quellserver, während auf Replicas der Status automatisch auf SLAVESIDE_DISABLED gesetzt wird. Das verhindert, dass dieselbe Datenänderung gleichzeitig auf mehreren Servern ausgeführt und über die Replikation erneut angewendet wird, was zu Dateninkonsistenzen führen würde.

Nach einem Failover, bei dem ein bisheriger Replica zum neuen Primärserver befördert wird, muss der Event Scheduler auf dem neuen Primärserver aktiv eingeschaltet werden, da er dort typischerweise deaktiviert war. Dieser Schritt wird in Failover-Runbooks leicht vergessen, da er nicht Teil der üblichen Replikations-Topologie-Umschaltung ist, sondern zusätzlich manuell oder über ein Automatisierungsskript nachgezogen werden muss.

9. Sicherheitsaspekte: DEFINER und Best Practices für den produktiven Einsatz

Jedes Event läuft mit den vollständigen Rechten seines Definierers, also des Datenbanknutzers, der zum Zeitpunkt der Erstellung als aktueller Nutzer eingetragen war, unabhängig davon, welcher Nutzer später tatsächlich mit der Datenbank verbunden ist. Ein Event, das versehentlich unter dem root-Konto oder einem anderen hochprivilegierten Nutzer angelegt wurde, führt seine Anweisungen dauerhaft mit diesen weitreichenden Rechten aus, selbst wenn die eigentliche Aufgabe nur minimale Rechte benötigen würde.

Für einen sauberen produktiven Einsatz empfiehlt sich deshalb ein dediziertes, auf die tatsächlich benötigten Tabellen und Operationen beschränktes Datenbankkonto als Definierer für alle Events, kombiniert mit einer aussagekräftigen COMMENT-Angabe bei jedem Event, die Zweck und Verantwortlichkeit dokumentiert. Zusammen mit regelmäßiger Prüfung über information_schema.EVENTS ergibt sich so ein Werkzeug, das seine Stärken bei klar begrenzten, rein datenbezogenen Aufgaben ausspielt, ohne zu einem unübersichtlichen Ersatz für ein vollwertiges Job-Scheduling-System zu werden.

-- Event unter einem dedizierten, eingeschraenkten Konto erzeugen
CREATE DEFINER='event_runner'@'localhost' EVENT ev_cleanup_expired_carts
ON SCHEDULE EVERY 1 HOUR
COMMENT 'Entfernt abgelaufene Warenkorb-Reste, Owner: Platform-Team'
DO
  DELETE FROM quote WHERE is_active = 0 AND updated_at < NOW() - INTERVAL 30 DAY;

-- Definierer eines bestehenden Events prüfen
SELECT EVENT_NAME, DEFINER FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'magento';

10. Zusammenfassung

11. FAQ: Der MySQL Event Scheduler: das Wichtigste auf einen Blick