|
為什么需要超過7個結(jié)點的Replica Sets？
本文是一篇譯文，原文見到boxedice公司的官方博客，他們在應(yīng)用中使用了MongoDB 的 replica sets機制，但不僅是為了數(shù)據(jù)的安全性，因此replica sets 7個節(jié)點的限制在這里顯得尤為有用。下面我們來看一下他們的使用經(jīng)驗吧。
原文鏈接：When would ever need more than 7 replica set members?
MongoDB 的Replica sets是一個升級版的主從機制，不同的是，它提供了一個機制，使得在主結(jié)點出現(xiàn)故障后其中一個從結(jié)點可以自動轉(zhuǎn)移為主結(jié)點。在我們的應(yīng)用中，我們我們的每一個sharding結(jié)點是一個由四個replica sets數(shù)據(jù)結(jié)點加一個replica sets arbiter組成。MongoDB 的replica sets最多可以設(shè)置7個結(jié)點，為什么我們需要這么多的結(jié)點呢？為什么在我們的應(yīng)用中，我們需要有4份數(shù)據(jù)備份呢？
在MongoDB 的郵件列表里有一個討論，其中說到Google的數(shù)據(jù)也只有3到4份備份。對于數(shù)據(jù)安全性來說，3到4份確實足夠了，但是如果你想在不同地域有一份備份，那么可能3到4份就不夠了。比如我們的應(yīng)用，我們在不同的兩個地域分別有兩個備份。
Why?
我們的每一個replica set結(jié)點都存儲了400GB的數(shù)據(jù)，當(dāng)一個結(jié)點出現(xiàn)故障后，它可能在未來某個時間點重新恢復(fù)過來，這時候他需要重新同步最新的數(shù)據(jù)。如果故障時間不長，那我們可以增量地通過主服務(wù)器的oplog來將故障時間內(nèi)的更新操作同步過來執(zhí)行，但是如果故障時間超過了oplog所存儲的更新范圍（nosqlfan：oplog的存儲是在capped collection中，這種collection只有一定大小，超過大小后會將舊數(shù)據(jù)進行刪除，所以oplog中只會有最近一段時間的更新日志。），這這種情況下，我們必須要對數(shù)據(jù)進行全量的同步。
從異地遠程全量同步，對于我們的400GB數(shù)據(jù)來說，會耗費很長的時候，大概是幾天。但是由于我們在同一個機房里還存在一個節(jié)點，如果我們從這個結(jié)點進行備份，那就會很快。
也就是說，我們可以將同一機房的另一個節(jié)點停機，然后將數(shù)據(jù)備份給出現(xiàn)故障剛剛恢復(fù)的這個節(jié)點。同機房的數(shù)據(jù)拷貝是很快的。也就是說我們有兩套恢復(fù)方案，耗時地從遠端的master機器上備份或者快速地從同一機房的另一個節(jié)進行備份。
如果你的數(shù)據(jù)量沒有我們這么大，那沒有什么關(guān)系，但是對我們來說，必須保證在同一機房能有超過一個結(jié)點。MongoDB 7個結(jié)點的限制讓我們可以在三個不同地域分別設(shè)置兩個結(jié)點，還剩一個節(jié)點可以做arbiter。但是在Google的最多3，4個結(jié)點的限制下，這種任務(wù)就沒法完成了。
—————-本站觀點—————–
其實MongoDB提供的replica sets機制，從來都不是為了不同IDC之間的類似于CDN一樣的功能服務(wù)的，他看重的僅僅是數(shù)據(jù)的安全性，對于多IDC的內(nèi)容同步，我想我們應(yīng)該更多的通過應(yīng)用層來保證，而且鑒于天朝這種讓人發(fā)指的網(wǎng)絡(luò)狀況，在公司沒有花大價租用專用通道的前提下，這種依靠replica sets來做數(shù)據(jù)分發(fā)的想法更不切實際。
所以在這里奉勸各位，最好是按照開發(fā)者的意圖去使用特定的功能，這樣也是使你的功能能夠得開發(fā)者持續(xù)支持的好習(xí)慣。
| 
免費注冊
發(fā)表于 2012-02-22 19:09
