Why MySQL’s event_scheduler Survives Kill Commands During Master‑Slave Switch and How to Use Events

Background

During a MySQL master‑slave failover, the primary server typically performs three actions: unbind the VIP, set the instance to read‑only, and kill residual connections. The replica must apply missing binlogs, clear read‑only mode, remove replication info, and rebind the VIP.

In MySQL 8.0, killing residual connections sometimes logs a warning like

[warn] kill process warning：Error 1094：Unknown thread id：4

. This warning does not appear in MySQL 5.7.

The warning originates from the internal event_scheduler thread, whose user appears as event_scheduler in processlist.

What is event_scheduler ?

event_scheduler

is a special MySQL thread that executes events defined by the MySQL Event Scheduler, similar to Linux crontab. When event_scheduler=ON, MySQL starts this daemon thread, which continuously runs and launches a new session for each scheduled event.

In MySQL 5.7 the scheduler is disabled by default, while MySQL 8.0 enables it, which explains why the warning only appears in 8.0.

Why the event_scheduler thread cannot be killed

The event_scheduler appears in processlist with COMMAND=Daemon. Because it is an internal daemon thread, not a user‑initiated session, the KILL command cannot terminate it, resulting in the “Unknown thread id” warning.

Using MySQL scheduled events

Below are the essential commands for managing events.

Enable / Disable / Disable permanently

-- Check current setting
SHOW VARIABLES LIKE '%event_scheduler%';

-- Disable temporarily
SET GLOBAL event_scheduler = 0;

-- Enable
SET GLOBAL event_scheduler = 1;

-- Disable permanently (requires server restart)
[mysqld]
event_scheduler=DISABLED

Create an event

-- Create a test table
CREATE TABLE logs(
    id INT PRIMARY KEY AUTO_INCREMENT,
    log_message VARCHAR(255) NOT NULL,
    log_time TIMESTAMP NOT NULL
);

INSERT INTO logs (log_message, log_time) VALUES
    ('Sample 1', '2023-06-07 09:01:00'),
    ('Sample 2', '2023-06-07 23:02:00');

-- Create an event that deletes rows older than 7 days, running every minute
CREATE EVENT delete_logs_event
    ON SCHEDULE EVERY 1 MINUTE STARTS '2023-06-19 00:00:00'
    DO
        DELETE FROM logs
        WHERE log_time < DATE_SUB(NOW(), INTERVAL 7 DAY) LIMIT 1;

View events

-- Switch to the schema containing the event
USE universe;

-- List events
SHOW EVENTS\G;

-- Detailed info from information_schema
SELECT * FROM information_schema.events\G;

Modify an event

-- Change schedule to every day and remove LIMIT
ALTER EVENT delete_logs_event
    ON SCHEDULE EVERY 1 DAY STARTS '2023-06-19 00:00:00'
    DO
        DELETE FROM logs
        WHERE log_time < DATE_SUB(NOW(), INTERVAL 7 DAY);

Drop an event

DROP EVENT delete_logs_event;
SHOW EVENTS\G;  -- Should return empty set

Considerations during master‑slave switch

Events created on the original master remain in the event table after failover; they do not automatically start executing on the new master, and their status stays unchanged.

The original master’s event stays ENABLED, while the new master’s copy of the event is DISABLED.

Summary

The event_scheduler session shown by SHOW PROCESSLIST is an internal MySQL thread and cannot be killed.

Events created on the primary are replicated to the replica but are not re‑executed there.

After a failover, events on the former primary do not run on the new primary unless manually re‑enabled.