http://www.dev-club.net/xiangxixinxi/1087122010072906124317/201107260532452.html
這裏在簡單的介紹一下Master Slave/ Replica Sets 備份機制，這兩種模式都是基於主服務器的oplog來實現所有從服務器的同步。
oplog記錄了增刪改操作的記錄信息（不包含查詢的操作），但是oplog有大小限制，當超過指定大小，oplog會清空之前的記錄，重新開始記錄。（太坑爹了！！！）Master Slave 方式 主服備器會產生 oplog.$main 的日誌集合
Replica Sets
方式 所有服務器都會產生oplog.rs 日誌集合
兩種機制下，所有從服務器都會去輪詢主服務器oplog日誌，若主服務器的日誌較新，就會同步這些新的操作記錄。但是這裏有個很重要的問題，從服務器由於網絡阻塞，死機等原因無法極時同步主服務器oplog記錄：
一種情況： 主服務器oplog不斷刷新，這樣從服務器永遠無法追上主服務器。
另外一種情況：剛好主服務器oplog超出大小，清空了之前的oplog，這樣從服務器就與主服務器數據就可能會不一致了，這第二種情況，我是推斷的，沒有證實。
另外要說明一下Replica Sets 備份的缺點，當主服務器發生故障時，一臺從服務器被投票選爲了主服務器，但是這臺從服務的oplog如果晚於之前的主服務器oplog的話，那之前的主服務器恢復後，會回滾自己的oplog操作和新的主服務器oplog保持一致。由於這個過程是自動切換的，所以在無形之中就導致了部分數據丟失。
這裏看主從備份的操作：
主上：
[root@mongodb2 data]# more master_configfile
dbpath=/data/db/
master=true
logpath=/data/db/mongodb_master.log
port=27017
logappend=true
刪掉local.* 爲了重建oplogSize
/usr/local/mongodb/bin/mongod --oplogSize=8038 --configmaster_configfile &
可以查看一下：
[root@mongodb3 db]# /usr/local/mongodb/bin/mongo
MongoDB shell version: 1.8.0
connecting to: test
> db.printReplicationInfo()
configured oplog size: 8038MB
log length start to end: 0secs (0hrs)
oplog first event time: Wed Jul 27 2011 17:34:51GMT+0800 (CST)
oplog last event time: Wed Jul27 2011 17:34:51 GMT+0800 (CST)
now: Wed Jul 27 2011 17:36:32 GMT+0800 (CST)
從上
[root@mongodb1 data]# more slave_configfile
dbpath=/data/db/
slave=true
source=192.168.1.41:27017
slavedelay=30
logpath=/data/db/mongodb_slave.log
port=27017
logappend=true
啓動
/usr/local/mongodb/bin/mongod --configslave_configfile --autoresync &
等待數據同步完成後，可以在兩臺機器上db.表名.count()一下，對比看看數據數量
當主down機後
salve提成爲主：
$ rm /data/db/local.*
$ /usr/local/mongodb/bin/mongod --oplogSize=8038 --configmaster_configfile &
等主恢復後，讓他變成從，可能還需要重新rsync一次數據
/usr/local/mongodb/bin/mongod --configslave_configfile --autoresync &
關於oplog的概念請參考
http://blog.163.com/digoal@126/blog/static/163877040201011654535891/
兩種機制下，所有從服務器都會去輪詢主服務器oplog日誌，若主服務器的日誌較新，就會同步這些新的操作記錄。但是這裏有個很重要的問題，從服務器由於網絡阻塞，死機等原因無法極時同步主服務器oplog記錄：
一種情況： 主服務器oplog不斷刷新，這樣從服務器永遠無法追上主服務器。
另外一種情況：剛好主服務器oplog超出大小，清空了之前的oplog，這樣從服務器就與主服務器數據就可能會不一致了，這第二種情況，我是推斷的，沒有證實。
另外要說明一下Replica Sets 備份的缺點，當主服務器發生故障時，一臺從服務器被投票選爲了主服務器，但是這臺從服務的oplog如果晚於之前的主服務器oplog的話，那之前的主服務器恢復後，會回滾自己的oplog操作和新的主服務器oplog保持一致。由於這個過程是自動切換的，所以在無形之中就導致了部分數據丟失。
這裏看主從備份的操作：
主上：
[root@mongodb2 data]# more master_configfile
dbpath=/data/db/
master=true
logpath=/data/db/mongodb_master.log
port=27017
logappend=true
刪掉local.* 爲了重建oplogSize
/usr/local/mongodb/bin/mongod --oplogSize=8038 --configmaster_configfile &
可以查看一下：
[root@mongodb3 db]# /usr/local/mongodb/bin/mongo
MongoDB shell version: 1.8.0
connecting to: test
> db.printReplicationInfo()
configured oplog size: 8038MB
log length start to end: 0secs (0hrs)
oplog first event time: Wed Jul 27 2011 17:34:51GMT+0800 (CST)
oplog last event time: Wed Jul27 2011 17:34:51 GMT+0800 (CST)
now: Wed Jul 27 2011 17:36:32 GMT+0800 (CST)
從上
[root@mongodb1 data]# more slave_configfile
dbpath=/data/db/
slave=true
source=192.168.1.41:27017
slavedelay=30
logpath=/data/db/mongodb_slave.log
port=27017
logappend=true
啓動
/usr/local/mongodb/bin/mongod --configslave_configfile --autoresync &
等待數據同步完成後，可以在兩臺機器上db.表名.count()一下，對比看看數據數量
當主down機後
salve提成爲主：
$ rm /data/db/local.*
$ /usr/local/mongodb/bin/mongod --oplogSize=8038 --configmaster_configfile &
等主恢復後，讓他變成從，可能還需要重新rsync一次數據
/usr/local/mongodb/bin/mongod --configslave_configfile --autoresync &
|
一些問題 1，主上數據量很大，那麼這時候來做主從同步，從上的數據是不是必須從主同步過來，而不能把主上dump下的數據 放到從上restore在做主從同步？（我測試了一下如果先dump，restore後在做主從同步的話，這段時期的數據從是不會再去同步的） 2，主從同步做好了，過了一段時間從down機了，等從恢復後，會自動的去同步主上的數據嗎？（這個我測試是可以，但是數據量比較小，而且我模擬down機時間也比較短） 3，主down機後，是不是必須將從上的local.*文件刪除，然後以主的方式啓動？ |
|
| 解答： 1.最好是全部rsync一次，其實也可以把主做成master後在dump數據，從restore數據完之後會從主的oplog位置在同步 2.會的，除非oplog設置得不夠大，而偏偏主又把oplog清空了 3.也是必須的，因爲默認的slave是隻能讀不能寫，所以必須改成主的模式啓動 |
關於oplog的概念請參考
http://blog.163.com/digoal@126/blog/static/163877040201011654535891/
