MongoDB Replica Sets Problem

2012年5月19日星期六

MongoDB Replica Sets Problem

最近忙著要讓產品上線，主要的工作就是在調教Production 的環境，還有做整合測試，但是在MongoDB那邊吃足了苦頭，這幾天都是在跟MongoDB 打渾戰，因為遇到了資料在Replica Sets 不同步的問題，在討論這個問題和解法前，先介紹一下MongoDB的特色，以及為什麼要選用他。(~~因為偷懶吧...~~)

MongoDB的特色根據官網自己的描述：

Document-oriented storage (採用JSON，好改容易理解，但是也容易誤用)
Full Index Support (~~但是很肥~~)
Replication & High Availability (~~但是還是遇到一堆問題~囧~~)
Mirror across LANs and WANs for scale and peace of mind. (~~你不會想要讓他cross WAN的...~~)
Auto-Sharding (號稱最強大的祕密武器~~)
Document based Querying (真的要多Try & Error)
Fast In-Place Updates
Map/Reduce (研究中...)
GridFS (研究中..)

之所以會選MongoDB 最主要就是看上它以Replica Sets 的方式達到HA，以及AutoSharding的能力，一個Replica Sets由若干個mongod instance組成，在這個集合中，所有的instance的資料相同，這使得即使有某一台機子當掉了，其它機子還是可以正常運行，而這部分的控制是由Mongo自動完成的，用意在於減少因當機而產生的錯誤及人工處理的部分。(但是我還是遇到問題啊~~~~~~囧rz...)。

首先我的配置是參考了Foursquare的文章 Fun with mongodb replica sets 以及Mongod 官網教學[Upgrading to Replica Sets]，一開始啟動了三台Mongod instance，一台是Primary，一台是slave，一台是Arbiter (投票者)，設定步驟如下：

1. 分別在三台機器啟動 (/etc/hosts 彼此要看的到對方 )


> mongod --rest --replSet replSetServers

2. 在PRIMARY 那台做以下設定


> rs.initiate() 

> rs.add(“replSetServers01”) 

> rs.addArb(“replSetServers02”)  //(這台是投票用)

3. 移除多餘的Server (Optional)


> rs.remove("replSetServers04:27017")

接下來應該就可以正常運作了，一開始的確是用的很開心，但是漸漸的就會遇到一些奇怪的問題，比如說write-concern 的問題，然後我們是用Spring-data來操作mongo，也發現了spring-data的bug，但是這些問題都還算可以解決，最讓我不解的就是同步問題，理論上應該會Eventually Consistency，也就是我們把資料寫入primary，然後mongoDB會自動把資料同步到Slave去，讓其他Client可以讀取。我遇到的問題就是有一筆資料明明在primary已經消失，但是卻一直留在Slave上，然後我等到望眼欲穿，它也不會同步，我也不能手動從slave把它砍掉.......，然後我就在網路上找資料，判斷有可能是以下原因造成資料錯誤：

沒有用正常步驟到mongoDB 裡面下 db.shutdownServer()，而是直接kill process，可能因此造成資料損毀或不同不。
根據以下圖片來解釋，資料同步的方向應該是單向的，也就是primary write to slave，如果這時候primaryA 掛了，slaveB升格成primaryB，這時資料寫到primaryB，結果primaryA又回復，primaryB又變回slaveB，在那這段期間內產生的資料會發生什麼事呢？是不是就會產生孤兒？