記一次TokuMX資料庫叢集恢複

標籤：虛擬機器   一段   恢複   png   serve   完成   強制   ini   好用   

中午在昏睡中接到電話，伺服器擴容後資料庫啟動不了了，於是不假思索的想到了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資料庫叢集恢複