MySQL 8 添加了新的 clone 插件，被用于 MGR 的分布式恢復當中，也可以用來進行物理備份恢復。但是在進行 clone 操作的過程中，當拉取數據完成并進行自動重啟 server 時，總是會出現重啟失敗的現象，如：日志報錯提示 RESTART 失敗，需要在后面手動重啟，錯誤代碼3707，即：ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process)。而在關于 clone 的官方文檔相關鏈接：https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-remote.html中，也特別說明了這個報錯：意思說是當 recipient server 在 clone 數據拉取完成后會進行重啟操作，前提是監控進程可用。而當出現相關報錯時也不用擔心，并不能說明 clone 失敗了，隨后只需要手動重啟就可以了。通過上面的日志和官方文檔我們得到了出現重啟失敗的兩個線索：RESTART 、監控進程。先看關于 RESTART 的相關官方文檔說明（https://dev.mysql.com/doc/refman/8.0/en/restart.html）：通過這段文檔我們可以知道，如果想要成功執行“RESTART”命令，需要有一個監控進程，所以“RESTART”執行成功與否的關鍵就在于這個監控進程，而這個監控進程到底是什么文檔在后面也進行了說明：這時候我們就知道在類 Unix 系統中使用 systemd 或 mysqld_safe 來實現這個監控進程。但是有時當我們使用自建的 systemd 的 MySQL service 服務時，依舊不能實現自動重啟，而問題的關鍵還是在于沒有配置好相關的監控進程，我們可以參考官方 rpm 包安裝 MySQL Server 時生成的 systemd 的 service 文件的“[Service]”區域：Restart=on-failureRestartPreventExitStatus=1# Set enviroment variable MYSQLD_PARENT_PID. This is required for restart.Environment=MYSQLD_PARENT_PID=1官方的 systemd 的 service 文件已經指出了如果想要實現自動重啟，最重要的就是要設置“Environment=MYSQLD_PARENT_PID=1”，PID為1的進程就是 systemd 的進程。而官方設置的重啟時機是“on-failure” ， 即數據庫當遇到異常宕機、進程中斷信號或監控超時時就會進行重啟，但是當數據庫異常宕機時，有時我們并不想讓數據庫立刻自動重啟，而是需要在運維和開發人員確認過問題之后進行手動重啟，這時候我們就需要調整自動重啟的策略。在“RESTART”相關的官方文檔中，明確指出了“RESTART”命令執行時數據庫關閉時的退出狀態碼：16。這時我們就可以設置只有當數據庫退出狀態碼為16時才進行自動重啟，而在其余情況下不會進行自動重啟，MySQL 的 systemd 的 service 的“[Service]”區域進行如下配置：RestartForceExitStatus=16RestartPreventExitStatus=1# Set enviroment variable MYSQLD_PARENT_PID. This is required for restart.Environment=MYSQLD_PARENT_PID=1“RestartForceExitStatus=16”的意思就是說不管是否配置了“Restart=”，當服務的退出狀態碼為16時都會進行自動重啟，這樣就解決了 clone 自動重啟失敗的問題，同時也保證了數據庫在其他異常情況下不會進行自動重啟。如給 MySQL 發送中斷信號時不會自動重啟：當執行 clone 操作時可以自動重啟沒有了之前的報錯，進行自動重啟