Nosql之Cassandra 的Docker 除錯歷程,schema重置大法

Nosql之Cassandra 的Docker 除錯歷程,schema重置大法

早上因為自己的vm容量不太夠,所以開始關機調配了一下相關設定,重啟vm後,照慣例是要restart相關docker服務,結果就馬上遇到下面的狀況
Cassandra掛掉了…,restart數次都這樣,跑了二分鐘後,就exit
sudo docker ps -a
一開始我只知道看log的指令,先看看是遇到什麼鬼問題吧…
sudo docker logs {{containner id}}
如下圖log顯示,commitlog異常,讀取失敗,導致cassandra爆掉…,但log上寫的全部都是containner內部的相對位置,我怎麼追查呀?重開一個containner是很簡單…但資料因為沒有獨立出來,所以有一些設計的schema若重啟一個是不是會不見呀?想到這邊,還是覺得這是一種逃避,決定下海來找原因
以往ap跑不起來,我比較知道的查詢的方式,是必須shell進去 container,然後在runtime環境查問題。但containner根本跑不起來…怎麼辦?
然後當初是透過dokcerfile(吧?)跑指令,所以無從知道這個containner有沒有綁定volumn,若沒有的話,我該怎麼去追查cassandra的問題呢?
查了一小多小時,有一個command露出了一線曙光
我们可以使用docker inspect命令找到Volume在主机上的存储位置:
$ sudo docker inspect -f {{.Volumes}} container-test
以cassandra 異常,為例:我們可以透過docker得知預設volumn的位置,這些位置其實可以在起始指令的時候進行綁定
部分指令好位置的我覺得沒問題,dockerfile也應該查的到,但沒有dockerfile可以 參考的,我們就可以透過這個指定看到containner現況的所有相關資訊
 “Mounts”: [
            {
                “Name”: “31a88f59c57b5a75b98f9c4e6a539e4140cb226760fc540b15b930d96010a84c”,
                “Source”: “/var/lib/docker/volumes/31a88f59c57b5a75b98f9c4e6a539e4140cb226760fc540b15b930d96010a84c/_data“,
                “Destination”: “/var/lib/cassandra”,
                “Driver”: “local”,
                “Mode”: “”,
                “RW”: true,
                “Propagation”: “”
            }
檢查其下的volumns路徑,發現data/我的keyspace下怎麼這麼多這個file,原來是我先前透過工具去clone TABLE的時候,其實都會記錄下來…封存在這邊,這邊我先不管了,先把那些我rename過的目錄都刪掉…
docker restart 後以後,還是死掉…,到這邊,我想到…log中寫的是commitlog異常,我看到cassandra的volumn根目錄下有一個commitlog的目錄,我直接把裡面的檔案mv到/backup,再重啟一次…終於正常了,schema回來了
但…資料不見了?  shit!!所以這些commitlog才是跟資料有關,data則是只有schema??神奇啊…至目前為止,還好我是測試資料…schema比較重要,至於正式資料的環境我覺得根本不能這樣搞,但為何commitlog會讓cassandra掛掉,無法啟動,我還是不知道,至少這次經驗,成功重啟了,我猜測原因可能是我對cassandra建立了很多blob field,根本原因,等我有空再來研究看看,這些log裡面到是在賣什麼藥,幸好我有把commitlog備份出來…
先繼續其他nosql的測試了

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

WP Facebook Auto Publish Powered By : XYZScripts.com