Databases 15 min read

Understanding MySQL Event Scheduler and Why Its Connections Cannot Be Killed During Master‑Slave Switch

This article explains the MySQL event_scheduler thread, why killing it during master‑slave failover produces an "Unknown thread id" warning in MySQL 8.0, how to manage events, and the impact of these internal daemon sessions on replication and failover processes.

Aikesheng Open Source Community
Aikesheng Open Source Community
Aikesheng Open Source Community
Understanding MySQL Event Scheduler and Why Its Connections Cannot Be Killed During Master‑Slave Switch

1 Background

Before introducing the background, let’s briefly describe the MySQL master‑slave switch process.

When a master‑slave switch occurs, the primary (master) performs the following actions:

Disconnect traffic entry (unbind VIP)

Set read‑only mode

Kill residual connections

The replica (slave) performs these actions:

Apply missing binlog entries from the master

Disable read‑only mode

Clear replication information

Reconnect traffic entry (bind VIP)

Our in‑house database cluster management platform Yunshu® DMP follows a similar switch process, and the link to this article is the warn message that appears when the master kills residual connections.

During the kill operation, the log sometimes contains the warning:

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

In MySQL 5.7 this warning does not appear, but MySQL 8.0 reproduces it consistently. Further testing revealed that the "Unknown thread id" originates from a connection whose user is event_scheduler .

2 What Is event_scheduler?

The event_scheduler is a special MySQL thread responsible for executing events created by the MySQL Event Scheduler, similar to Linux crontab for timed tasks.

When the event scheduler is enabled ( event_scheduler=ON ), MySQL starts an event_scheduler thread that runs continuously until the server stops. The thread checks the current time against defined events and launches a new session to execute each due event.

Note that in MySQL 5.7 the event scheduler is disabled by default, while in MySQL 8.0 it is enabled, which explains why the warning does not appear in 5.7.

3 Why Can’t the Kill Command Remove It?

After understanding what event_scheduler is, we can see why killing it reports "Unknown thread id".

Inspecting processlist , the event_scheduler session shows a COMMAND value of Daemon . This indicates a background daemon thread, not a user‑initiated connection, and therefore it cannot be killed like ordinary sessions.

Official documentation provides little detail; interested readers can examine the source code.

4 How to Use Scheduled Events

There are many resources online for using MySQL events. Below is a simple example that creates an event to delete rows older than seven days from a log table, running once per minute for demonstration.

Enable / Disable / Disable Permanently

-- Modify variable event_scheduler to enable or disable dynamically
mysql> show variables like '%event_scheduler%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| event_scheduler| ON    |
+-----------------+-------+
1 row in set (0.00 sec)

-- Disable
mysql> SET GLOBAL event_scheduler = 0;

-- Enable
mysql> SET GLOBAL event_scheduler = 1;

-- Disable permanently (must be set in my.cnf)
[mysqld]
event_scheduler=DISABLED

Create Event

-- Prepare test table and data
mysql> CREATE TABLE logs(
    id INT(11) PRIMARY KEY AUTO_INCREMENT,
    log_message VARCHAR(255) NOT NULL,
    log_time TIMESTAMP NOT NULL
);

INSERT INTO logs (log_message, log_time) VALUES
    ('君不见黄河之水天上来,奔流到海不复回','2023-06-07 09:01:00'),
    ('君不见高堂明镜悲白发,朝如青丝暮成雪','2023-06-07 23:02:00'),
    ('人生得意须尽欢,莫使金樽空对月','2023-06-08 01:03:00'),
    ('天生我材必有用,千金散尽还复来','2023-06-08 18:04:00'),
    ('烹羊宰牛且为乐,会须一饮三百杯','2023-06-09 23:05:00'),
    ('钟鼓馔玉不足贵,但愿长醉不复醒','2023-06-09 11:06:00'),
    ('古来圣贤皆寂寞,惟有饮者留其名','2023-06-10 23:02:00'),
    ('陈王昔时宴平乐,斗酒十千恣欢谑','2023-06-11 01:03:00'),
    ('主人何为言少钱,径须沽取对君酌','2023-06-12 18:04:00'),
    ('五花马、千金裘','2023-06-13 23:05:00'),
    ('呼儿将出换美酒,与尔同销万古愁','2023-06-14 11:06:00');

-- Create event to delete logs older than 7 days, one row per minute for quick observation
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 Event

-- Show events (must use the schema where the event resides)
mysql> USE universe;
mysql> SHOW EVENTS\G
*************************** 1. row ***************************
Db: universe
Name: delete_logs_event
Definer: root@localhost
Time zone: SYSTEM
Type: RECURRING
Execute at: NULL
Interval value: 1
Interval field: MINUTE
Starts: 2023-06-19 00:00:00
Ends: NULL
Status: ENABLED
...

-- Detailed view via information_schema.events
mysql> SELECT * FROM information_schema.events\G
*************************** 1. row ***************************
EVENT_CATALOG: def
EVENT_SCHEMA: universe
EVENT_NAME: delete_logs_event
DEFINER: root@localhost
EVENT_DEFINITION: DELETE FROM logs WHERE log_time < DATE_SUB(NOW(), INTERVAL 7 DAY) limit 1
EVENT_TYPE: RECURRING
INTERVAL_VALUE: 1
INTERVAL_FIELD: MINUTE
STARTS: 2023-06-19 00:00:00
STATUS: ENABLED
...

Modify Event

-- Alter event (any high‑privilege user can do this; the DEFINER becomes the user who runs ALTER)
mysql> 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);

-- Verify change
mysql> SELECT * FROM information_schema.events\G
*************************** 1. row ***************************
... DEFINER: qin@% ... INTERVAL_FIELD: DAY ... STATUS: ENABLED ...

Delete Event

mysql> DROP EVENT delete_logs_event;
Query OK, 0 rows affected (0.01 sec)

mysql> SHOW EVENTS\G
Empty set (0.00 sec)

Switch‑over Considerations

When an event is created on the primary and a master‑slave switch occurs, the event does **not** automatically migrate to the new primary, and its status remains unchanged.

The original primary retains the event with status ENABLED , while the new primary shows the event as DISABLED .

5 Summary

The show processlist entry with user event_scheduler represents an internal MySQL thread that cannot be killed.

Events created on the master are replicated to the slave and executed there, but they are not re‑executed on the slave independently.

After a master‑slave switch, events that existed on the old master will not run on the new master unless manually re‑enabled.

References

[1] Yunshu® DMP: https://www.actionsky.com/cloudTreeDMP

MySQLReplicationDatabase AdministrationEvent SchedulerMaster-Slave SwitchSQL Events
Aikesheng Open Source Community
Written by

Aikesheng Open Source Community

The Aikesheng Open Source Community provides stable, enterprise‑grade MySQL open‑source tools and services, releases a premium open‑source component each year (1024), and continuously operates and maintains them.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.