1. 程式人生 > >記一次TokuMX數據庫集群恢復

記一次TokuMX數據庫集群恢復

關鍵詞 安裝路徑 bsp -a 連接 sys cfg and 安排

中午在昏睡中接到電話,服務器擴容後數據庫啟動不了了,於是不假思索的想到了TokuMX需要關閉對透明大頁的使用才可以正常啟動,而這點恰巧大家都不是很清楚,在這裏寫下關閉的shell: echo never > /sys/kernel/mm/transparent_hugepage/enabled 一般情況下將其寫入開機啟動腳本,否則數據庫不能正常啟動。

然而當我遠程查看了服務器後徹底懵逼了,數據庫不見了,印象中服務安裝在dev掛載點下,於是我翻遍了dev,全盤grep,find和tokumx相關的文件,後來只查到一些無關痛癢的東西,慌了。

誰會大意把數據庫刪了,或者說是我印象中記錯目錄了,慌亂中查找了home,opt,etc….等等等等,把整個服務器翻了個遍都沒有找到蹤跡,一個念頭一閃而過,不是每臺服務器都做了開機啟動嗎,裏邊兒不就有數據庫路徑。心知這個小問題要被解決掉了,打開rc.local一看:這是個大問題(其實我的內心是崩潰的,千萬頭羊駝在愉快地奔跑)..我不信,我不接受這個事實,於是又到dev下翻了個遍,各種grep,連find -name命令我都不相信。事實告訴我不信也沒用,然而沒有就是沒有。

技術分享圖片

我開始懷疑是不是有人刪掉了數據庫,此時我還是很淡定的,因為我們還有備份機,最差也能找到數據庫的正確安裝路徑吧。每當我沾沾自喜擁有聰明才智時,現實總會將我亂棒打醒。備份機離線了….電話得知為了擴容備份機也關了,於是告知開機取備份。然後,備份機也完蛋了,同樣的目錄,什麽也沒有…安排後事吧,死了就得葬,管殺就得管埋,領導負責給客戶做好善後工作,我開始埋。到此時我仍然認為是有人無意中覺得這個目錄下多了個奇怪的文件夾看著不順眼刪了,而這個目錄正好是我們的數據庫目錄。

於是我開始了漫無目的的查找系統日誌,各種搜索文件夾刪除日誌,linux系統日誌,查看了/var/log下的各種日誌並沒有得到任何有用的內容。

我甚至想到了數據恢復,網上看了各種linux系統下的數據恢復方式和工具,嘗試了各種搜索,但是想到了之前一些事情的粗心大意考慮欠穩妥,於是把數據恢復方案作為最後的手段,告一段落。。。

理理思路,因為主服務的數據庫裝載dev掛載點下,備份機為了保持一致也方便記憶,也沒多想都裝同一掛載點了,於是改變了搜索關鍵詞:dev子目錄丟失,我想我得到了答案

技術分享圖片

仍然不死心,直到我看到了這個答案後的嘗試。mount /dev/mongodb ,各種mount,花式mount,提示在/etc/estab/ 下並沒有此掛載點,事實上是沒有此掛載點的記錄,多次嘗試,沒用。

技術分享圖片

為了證明上面說法的真實性,親手做了實驗,在dev下建立了test目錄,裏面touch了123.txt,reboot,查看,沒了。

意思很明確,數據庫找不回來了,所有的東西都得從頭開始。功夫不負有心人,領導的提示,我想到了補救措施,數據庫文件和數據庫應該不在同一目錄下,欣喜的發現了庫裏的所有文件一一羅列在此了(這個目錄的名稱toku拼寫錯了)

技術分享圖片

接下來怎麽辦,想到初來公司時就是因為誤改了數據庫路徑導致了數據庫加載不上,然而就算是有這些文件沒有原來的集群配置又有什麽用。但是想想這麽大的公司做出來的軟件不應該會這麽傻,而當初是因為對linux操作系統和mongodb的不了解和畏懼沒有深究導致的,這次不論如何我要把這些數據恢復回去。

此時因為以前用mongodb時試過直接更改配置文件中的dbpath是不管用的,甚至不確定更改了dbpath配置數據庫文件會不會被重建,本著謹慎的態度我重裝了tokumx,這次將數據庫安裝指定在home目錄下,數據庫文件目錄也指定在新的tokumx安裝目錄下:/home/tokumx/data/(感慨一下一鍵安裝真好用,省了不少時間)。

到這裏兩臺服務器的tokumx重裝完畢,集群貌似有點小問題,手動處理了一下將集群恢復。

這次和之前不一樣的地方在於,數據庫是以集群的方式運轉的,假設只恢復了數據那麽集群是否還能正常運轉?不管怎麽樣先弄好一臺服務器用standalone模式也行,於是我搜索各種mongodb數據導入方式,得知用mongoimport,用mongoimport –h查看了幫助,告知用--dbpath指定導入文件夾。於是./mongoimport --dbpath /home/cdasTuko/data/ 結果呢,mongoimport只支持json,csv等等類型的導入。於是接著搜索如何直接加載數據庫文件,像sqlserver的分離和加載那樣,得不到任何有用的答案。Mongorestore也不適用。

後來想了想TokuMX畢竟不是Mongodb,它有更多人性化的一面,何不嘗試一下直接修改dbpath,萬一能加載上呢,就算沒了還有備份機呢。給自己壯了壯膽,確認了備份機上的數據庫文件存在後開始動手。

理了下思路,大概是這樣的:為了不影響集群,先修改standalone模式的配置文件,以非集群的方式啟動,如果能加載上就把集群的配置文件做同樣修改,如果集群啟動不了就刪除一臺機器的數據庫讓集群自動同步過去。

停止數據庫服務

./mongod –shutdown –f tokuShard.cfg

修改standalone的配置文件

vi tokumx.cfg

修改:dbpath=/home/cdasTuko/data/

重新啟動,用standalone的配置

./mongod –f tokumx.cfg

啟動完成,趕緊查了查數據,一個不少都在。成功!激動萬分!

接下來的工作就簡單了,數據在,數據庫在,集群搭起來不就好了,於是按照上述方法修改了tokuShard.cfg 將裏面的dbpath更變成舊的數據庫路徑,備份機的也一樣。修改完成,分別以集群配置文件啟動兩臺服務器的TokuMX,萬分幸運,成功了。此時雖已淩晨卻因高興完全沒睡意,興沖沖的連接到集群看了看狀態

技術分享圖片

STARTUP2是個什麽鬼?能吃嗎???搜索了關於Mongo集群的stateStr的各種含義,等待,1分鐘,2分鐘,5分鐘,10分鐘過去了 ,仍然是STARTUP2,心想不好,有事情要發生。趕緊打開RoboMongo查了查庫,果不其然,兩臺服務器都不能查詢,處於假死狀態,任何操作都不管用。再一次心灰意冷。

仔細看了看上面顯示的時間,又懵了,完全對不上號,於是用date命令查看了兩臺服務器的時間,相差1分鐘左右,會不會是因為這裏導致同步不了,用date –s 命令手動修改了兩臺服務器時間,讓其保持相差在10秒之內(時間同步服務可能沒有起作用)。

date –s 02:44

然後shutdown集群,重新啟動。情況沒有轉變,再看了看rs.status(),看到狀態:

replSet initial sync pending

集群初始化同步掛起…於是按照此關鍵詞搜索了一堆文章,有人提出使用rs.SlaveOK(),分別在兩臺服務器上執行,無果。想到了集群的特殊性,是否不能直接去修改數據庫路徑,否則影響到集群正常運轉,是否有其它配置記錄在admin或者local庫裏,於是我翻遍了兩臺服務器的local和admin庫的表,得到唯一感覺不大對的是集群操作日誌表中的dbpath字段還記錄著安裝時的/home/tokumx/data/ ,雖然是日誌感覺沒什麽用吧,反正已經到這一步了,就把看到的dbpath都替換成舊的數據庫文件路徑(/home/cdasTuko/data/)。

想了想覺得正常的集群配置和現在的是不是有什麽差別,於是打開了本地的虛擬機,查看了虛擬機上的local庫,發現並無差異。

可能是興奮沖昏了頭腦,許久才想起來還有日誌,為了清晰明了,我清空了日誌文件夾,重新啟動集群,5分鐘後趕緊打開了log文件cat /home/tokumx/log/tokumx.log

我看到了幾行非常有意思的話

技術分享圖片

我找不到主服務,而且我不能選舉自己(因為是主從備份)

於是搜索到了如下的解決方案,重置集群配置:

技術分享圖片

技術分享圖片

在兩臺服務器上分別執行後並沒有什麽效果,即使使用admin登錄也完全沒用。後來找到相關資料說,集群在選舉主服務的時候會有個優先級,修改優先級後重啟集群會選舉出主服務,於是我們連接到集群,獲取到配置文件,這裏將其中一臺優先級調到3:

config=rs.config()

config.members[0].priority=3 (這裏數字越大表示優先級越高,默認是1)

技術分享圖片

然而我得到的還是失敗。雖有個備選方案就是刪掉備份機的所有數據,重置集群,自動去同步主服務的數據,但是這個方案動靜太大,難以確保萬無一失,數據量之大不知道什麽時候才能同步完,迫不得已再使用此方案。

於是回到初始問題上,集群卡在狀態StartUp2上,花樣搜索嘛,國內沒有什麽有用的信息,看來還得求助歪果仁了,改變搜索內容:replicaset stuck at startup2。別說還真管用,萬能的stackoverflow,以負載均衡聞名程序猿界的網站得到了答案

技術分享圖片

看了看樓主和解答者的對話,發現和我遇到的一模一樣.

技術分享圖片

這裏版主和解答者的對話有好幾種解決方案,步驟寫的很詳細,內容較多這裏貼上地址

http://stackoverflow.com/questions/21642396/mongodb-all-replset-stuck-at-startup2

這裏我只使用了第一步,強制重置集群狀態,敲下回車的那一刻我知道管用了,別問我為什麽知道,因為我看見它卡住不動了,而不是立馬返回了錯誤信息。

丟了個盹兒,大概過了半個小時,回到服務器一看報錯了,但是緊接著下面的集群狀態已經是PRIMARY。這意味著這麽久的努力終於得到回報了。

技術分享圖片

大悲大喜,情緒起伏的一晚上,真是驚心動魄也無比歡樂,大問題解決了還睡什麽覺,趁剛做完還有印象,趁熱打鐵記下此文,以備不時之患。

記一次TokuMX數據庫集群恢復