作者：秦廣飛

愛可生 DBA 團隊成員，負責項目日常問題處理及公司平臺問題排查，對數據庫有興趣，對技術有想法。一入 IT 深似海，從此節操是路人。

本文來源：愛可生開源社區

1背景

照例要先講下本文檔背景的，不過在介紹背景之前，先簡單說下 MySQL 主從切換的過程。

正常來說，當要發生主從切換時，主庫要做下面幾個動作：

斷開流量入口（解綁 VIP）

設置只讀

Kill 掉數據庫殘留連接

而從庫，要做下面幾個動作：

補全與主庫差異的 binlog 日志

關閉只讀

清除復制信息

開啟流量入口（綁定 VIP）

我們公司自研的數據庫集群管理平臺 云樹 DMP[1] 大概也是這么個切換過程，而這個切換過程跟本文的關聯點，就在主庫 Kill 掉殘留連接上。

偶然間發現，DMP 在切換過程中 Kill 殘留連接時，日志中有時會出現 warn 信息：[warn] kill process warning：Error 1094：Unknown thread id：4

后來觀察到，MySQL 5.7 的主從切換時，就不會出現這個 warning 信息，而 MySQL 8.0 就會穩定復現。進一步測試驗證后，終于發現了這個 Unknown thread id 的真面目，就是 USER 為 event_scheduler 的這個"連接"。

2什么是 event_scheduler？

event_scheduler 到底是什么呢？畢竟從 processlist 信息中可以看到，它與普通的會話似乎不太一樣。

其實它是 MySQL 中的一個特殊線程，主要負責執行 MySQL 事件調度器所創建的事件。我們知道 MySQL 是有 event 的，可以像 Linux 中 crontab 一樣，定時執行一些任務。

The MySQL Event Scheduler manages the scheduling and execution of events, that is, tasks that run according to a schedule

當 MySQL 事件調度器啟用時 event_scheduler=ON，MySQL 就會在后臺啟動一個 event_scheduler 線程，并且 event_scheduler 線程將一直運行，直到 MySQL 服務停止。該線程會負責檢查當前時間和已定義的事件，如果事件需要執行，則 event_scheduler 線程將啟動一個新的會話來執行事件。

需要注意的是，在 MySQL 5.7中，event_scheduler 默認是關閉的，而 MySQL 8.0 中則默認打開了，而這也就是為什么在 MySQL 5.7 的切換過程中沒有發現 warning 信息的原因。

3為什么 Kill 不掉？

了解 event_scheduler 大概是什么之后，我們再來看看，為什么 Kill 時，會報 Unknown thread id。

注意看 processlist 信息，我們發現 event_scheduler 的 COMMAND 值為 Daemon。從字面意思上看，Daemon 為后臺守護的意思，其實在 MySQL 中，當在后臺運行一些特殊的功能時，會話 COMMAND 可能被標記為 Daemon（實際工作場景中，只注意到過 event_scheduler）。

因為這類會話并不是由用戶直接發起的連接，而是 MySQL 內部的線程，所以無法像普通會話一樣被 Kill 掉。

官方文檔中，給出的信息較少，大家有興趣的可以自己翻下代碼。

4如何使用定時任務？

具體如何使用定時任務，其實網上也有很多資料，如果真有需要使用的，建議最好參考官方文檔。下面我們簡單使用下 event 看看效果。

啟用/關閉/禁用

--修改變量event_scheduler來動態啟用或者關閉event
mysql>showvariableslike'%event_scheduler%';
+-----------------+-------+
|Variable_name|Value|
+-----------------+-------+
|event_scheduler|ON|
+-----------------+-------+
1rowinset(0.00sec)

mysql>

--關閉
mysql>SETGLOBALevent_scheduler=0;

--啟用
mysql>SETGLOBALevent_scheduler=1;

--禁用event_scheduler，只能在配置文件中設置event_scheduler為disable并重啟服務，而不能動態修改
[mysqld]
event_scheduler=DISABLED

創建

--準備測試表和數據
mysql>CREATETABLElogs(idINT(11)primarykeyAUTO_INCREMENT,log_messageVARCHAR(255)NOTNULL,log_timeTIMESTAMPNOTNULL);
QueryOK,0rowsaffected,1warning(0.02sec)

mysql>INSERTINTOlogs(log_message,log_time)VALUES
->('君不見黃河之水天上來，奔流到海不復回','2023-06-070900'),
->('君不見高堂明鏡悲白發，朝如青絲暮成雪','2023-06-072300'),
->('人生得意須盡歡，莫使金樽空對月','2023-06-080100'),
->('天生我材必有用，千金散盡還復來','2023-06-081800'),
->('烹羊宰牛且為樂，會須一飲三百杯','2023-06-092300'),
->('鐘鼓饌玉不足貴，但愿長醉不復醒','2023-06-091100'),
->('古來圣賢皆寂寞，惟有飲者留其名','2023-06-102300'),
->('陳王昔時宴平樂，斗酒十千恣歡謔','2023-06-110100'),
->('主人何為言少錢，徑須沽取對君酌','2023-06-121800'),
->('五花馬、千金裘','2023-06-132300'),
->('呼兒將出換美酒，與爾同銷萬古愁','2023-06-141100');
QueryOK,11rowsaffected(0.01sec)
Records:11Duplicates:0Warnings:0

mysql>

--創建event，實現定時將該日志表中7天之前的數據刪除
--為了快速看到效果，我們每分鐘執行一次，一次刪除1行
mysql>CREATEEVENTdelete_logs_event
->ONSCHEDULEEVERY1MINUTESTARTS'2023-06-190000'
->DO
->DELETEFROMlogs
->WHERElog_time

	

	查看

	
--執行showevents查看，需要先進到event所在的schema
mysql>useuniverse
mysql>showeventsG
***************************1.row***************************
Db:universe
Name:delete_logs_event
Definer:root@localhost
Timezone:SYSTEM
Type:RECURRING
Executeat:NULL
Intervalvalue:1
Intervalfield:MINUTE
Starts:2023-06-190000
Ends:NULL
Status:ENABLED
Originator:1862993913
character_set_client:utf8mb4
collation_connection:utf8mb4_0900_ai_ci
DatabaseCollation:utf8mb4_bin
1rowinset(0.00sec)

mysql>

--通過information_schema.events可以看到更詳細的信息
mysql>select*frominformation_schema.eventsG
***************************1.row***************************
EVENT_CATALOG:def
EVENT_SCHEMA:universe
EVENT_NAME:delete_logs_event
DEFINER:root@localhost
TIME_ZONE:SYSTEM
EVENT_BODY:SQL
EVENT_DEFINITION:DELETEFROMlogs
WHERElog_time

--查看表中是否被定時刪除
mysql>select*fromlogs;
+----+--------------------------------------------------------+---------------------+
|id|log_message|log_time|
+----+--------------------------------------------------------+---------------------+
|2|君不見高堂明鏡悲白發，朝如青絲暮成雪|2023-06-072300|
|3|人生得意須盡歡，莫使金樽空對月|2023-06-080100|
|4|天生我材必有用，千金散盡還復來|2023-06-081800|
|5|烹羊宰牛且為樂，會須一飲三百杯|2023-06-092300|
|6|鐘鼓饌玉不足貴，但愿長醉不復醒|2023-06-091100|
|7|古來圣賢皆寂寞，惟有飲者留其名|2023-06-102300|
|8|陳王昔時宴平樂，斗酒十千恣歡謔|2023-06-110100|
|9|主人何為言少錢，徑須沽取對君酌|2023-06-121800|
|10|五花馬、千金裘|2023-06-132300|
|11|呼兒將出換美酒，與爾同銷萬古愁|2023-06-141100|
+----+--------------------------------------------------------+---------------------+
10rowsinset(0.00sec)

mysql>

--查看showprocesslist中event_scheduler的信息，可以看到stats為Waitingfornextactivation
mysql>select*frominformation_schema.processlistwhereuser='event_scheduler';
+-------+-----------------+-----------+------+---------+------+-----------------------------+------+
|ID|USER|HOST|DB|COMMAND|TIME|STATE|INFO|
+-------+-----------------+-----------+------+---------+------+-----------------------------+------+
|12869|event_scheduler|localhost|NULL|Daemon|58|Waitingfornextactivation|NULL|
+-------+-----------------+-----------+------+---------+------+-----------------------------+------+
1rowinset(0.00sec)

mysql>

--我們在從庫上看下event的信息，可以看到STATUS為SLAVESIDE_DISABLED，因此不用擔心從庫重復執行event
mysql>select*frominformation_schema.eventsG
***************************1.row***************************
EVENT_CATALOG:def
EVENT_SCHEMA:universe
EVENT_NAME:delete_logs_event
DEFINER:root@localhost
TIME_ZONE:SYSTEM
EVENT_BODY:SQL
EVENT_DEFINITION:DELETEFROMlogs
WHERElog_time

	

	修改

	
--使用ALTER語句修改，其他高權限用戶也可以執行，且event的用戶會變成最后一個ALTER的用戶
mysql>ALTEREVENTdelete_logs_event
->ONSCHEDULEEVERY1DAYSTARTS'2023-06-190000'
->DO
->DELETEFROMlogs
->WHERElog_time

--可以看到DEFINER已經變成了修改的用戶，且時間間隔也修改為了1天，DELETE語句也去掉了LIMIT
mysql>select*frominformation_schema.eventsG
***************************1.row***************************
EVENT_CATALOG:def
EVENT_SCHEMA:universe
EVENT_NAME:delete_logs_event
DEFINER:qin@%
TIME_ZONE:SYSTEM
EVENT_BODY:SQL
EVENT_DEFINITION:DELETEFROMlogs
WHERElog_time

	

	刪除

	
mysql>dropeventdelete_logs_event;
QueryOK,0rowsaffected(0.01sec)

mysql>showeventsG
Emptyset(0.00sec)


	

	切換時注意

	當在主庫上創建了 event，之后發生了主從切換。此時 event 并不會隨著切換而變成在新主上執行，且狀態也不會發生改變。

	即原主 event 的狀態還是 ENABLED，而新主 event 的狀態還是 DISABLED。

	

	5總結

	show processlist 中看到的 User 為 event_scheduler 的會話為 MySQL 內部線程，無法被 Kill 掉。

	在主庫上創建的 event，定時執行的 SQL 語句，在從庫上會正常隨著復制回放，但不會被重復執行。

	主從切換后，原主上的 event 不會在新主上執行。

	審核編輯：湯梓紅