今天上班的路上收到一條短信，顯示線上所有實例備份都失敗了。備份失敗是大事，於是到公司的第一件事兒就是排查備份失敗的原因。

　　這兩天遷移了數據庫管理平臺，當然涉及到數據庫備份功能，備份失敗肯定和平臺遷移有一定關系，我們先聊聊線上備份方案：

　　目前線上的備份方案是：

　　　　1、有一個前端頁面可以配置備份任務

　　　　2、備份任務配置好了，會自動刷新到系統的crontab定時通過ansible遠程執行。

排查過程：

1、查看備份報告，顯示所有的備份文件大小都是0，初步估計是備份失敗了而不是元數據沒有更新的問題。

2、去機器上面查看備份日誌：

從日誌上面查看是備份已經成功，但是去過去備份文件大小的時候拋文件不存在的異常。

不知道大家有沒遇到這種情況，不過問看到這種現象首先想到的是有多個任務在跑，上一個備份還沒完成就被另外一個備份任務將備份文件刪除了。方面就初步出來了，就是要找到另外一個任務是怎麽來的。

3、我先挑選了一個比較小的非核心集群，嘗試了手動執行了crontab裏面的備份命令，備份成功(這只是確認一下，因為平臺遷移後測試過備份任務是沒有問題的)

4、由於每一個集群的備份全部失敗了，也就是說，兩個備份任務能連接到線上所有的mysql機器，有這權限的只有3臺服務器，於是去查了這三臺服務器是否有重復的定時任務。結果只有一臺機器上面才定時任務。

5、上面的嘗試也沒找到原因，就只能繼續嘗試，將備份任務的時間修改為當前時間+2分鐘，讓它定時執行看是否正常。

結果和晚上備份情況一樣還是失敗。

6、到這個時候我已經有點懵了，感覺這個太不科學了，期間還讓開發平臺的同事幫忙查看了代碼裏面生成crontab部分是否有問題，比如在其他機器上同時有生成，結果都是大失所望。

7、繼續其他嘗試，對比手動執行和定時任務產生的進程：

在目標機器使用ps -ef |grep backup.sh

a) 手動執行的時候：為2個進程

b) crontab定時執行的時候：為4個進程，

這個還是只能肯定定時任務有問題，並不能說明什麽原因造成這個現象的。

只能繼續蒙圈…………

8、在不知道怎麽排查問題的時候，我做了一個新的嘗試。

在配置好定時任務的時候，在中控機上使用service crond stop 將定時服務給停了，如果備份成功了那說明需要在其他機器找問題

9、這次嘗試確實後備份確實成功了，但是在其他機器也找不到原因，這時候 已經很抓狂了，完全不知道什麽情況了。

在準備放棄的時候，我在中控機上面使用 ps -ef |grep crond 查看crond 服務的情況。尼瑪，內心10000個草泥馬飛奔，居然還有有一個crond服務！！

使用service crond start 啟動crond，

居然有兩個服務。

看到這裏終於可以松口氣，看來問題就在這裏了，

於是將多余的crond 服務 kill掉後備份就正常。

ps：crond 這個服務個人確實從來沒發現可以啟動兩個的，後面我做了各種嘗試，最終還是只有一個服務，至今也不知道這個第二個crond服務怎麽起來的。

遇到自己感覺靈異的問題，我們要相信機器不會撒謊，我們要保持清晰的思路，堅持下去，終究能找到問題所在的。

話是這麽說，但是事實上做起來還是很難的，我差點就放棄，準備將這套備份系統直接下了，用自己新寫的一套來替代，本地已經測試ok，只要上線跑跑就可以了。不過還是挺慶幸當時沒有放棄，如果放棄了，那麽我也就錯過了crond服務還有可能出現兩個的奇觀了！

嘿嘿，提個問題，如果你們遇到這種情況，會用什麽思路來排查呢？

記crond導致備份失敗的排查過程