一、mongodb複制
1、mongodb複制簡介
mongodb複制的實作有兩種類型:
master/slave:和mysql主從複制非常近似,已經很少用了,
replica set:複制集或副本集,能自動實作故障轉移
副本集
服務于同一資料集的一組mongodb執行個體
一個複制集隻能有一個主節點,能讀寫,其它從節點隻能讀
主節點将資料修改操作儲存至oplog(記錄檔)中,各從節點通過oplog來複制資料并應用在本地
mongodb的複制至少需要兩個節點,一般為3個節點或更多節點,即使隻需要2個節點就夠用時也應該使用令一個節點當做仲裁裝置,可以不儲存資料(如果隻有一主一從的話,故障時不知道到底是主故障了還是從故障了)
副本集中各節點之間不斷通過心跳資訊傳遞來判斷健康狀态,預設心跳資訊每隔2s傳遞一次,一旦和主節點與其它節點中斷通信超過10s,副本集就會觸發重新選舉,選舉一個從節點成為新的主節點
副本集特征:
奇數個節點的叢集,應至少為3個節點,
任何節點可作為主節點,且隻能有一個主節點
所有寫入操作都在主節點上
自動故障轉移,自動恢複
副本集中節點分類:
0優先級的節點:
冷備節點,不會被選舉為主節點,但能參與選舉過程,并持有資料集,能被用戶端通路;常用于異地容災
被隐藏的從節點:
首先得是0優先級的節點,且對用戶端不可見
延遲複制的節點:
首先得是0優先級的節點,且複制時間落後于主節點一個固定時長
arbiter:
仲裁節點,不持有資料集
2、mongodb副本集
hearbeat:
實作心跳資訊傳遞,并觸發選舉
oplog:
儲存資料修改操作,是實作複制的基礎工具
大小固定的檔案,存儲在local資料庫中,複制集中各節點都有oplog,但隻有主節點才會寫oplog,并同步給從節點,
oplog具有幂等性,多次運作,結果不變
因為oplog的大小是固定的,不可能保持主節點的所有操作,是以從節點添加進複制集會先初始化:從節點先從主節點的資料集複制資料,并跟上主節點,然後才從oplog複制資料
1個新從節點加入複制集合後的操作過程:
初始同步(initial sync)
復原後追趕(post-rollback catch-up)
切分塊遷移(sharding chunk migrations)
local資料庫:
local資料庫本身不參與複制(不會複制到别的節點去)
存放了副本集的所有中繼資料和oplog;用于存儲oplog的是一個名為oplog.rs的collection(該節點加入了副本集後第一次啟動時自動建立);
oplog.rs的大小依賴于os及檔案系統,預設為磁盤空間的5%(此值少于1g時為1g);但可以自定義其大小:使用oplogsize=n機關為m
3、mongo的資料同步類型
1)初始同步
從節點沒有任何資料時,但主節點已有資料
從節點丢失副本複制曆史時
初始同步的步驟:
a、克隆所有資料庫
b、應用資料集的所有改變:複制oplog并應用于本地
c、為所有collection建構索引
2)複制
二、副本集的配置
1、環境
node2: centos6.5 x86_64
node5: centos6.5 x86_64
node7: centos6.5 x86_64
2、配置過程
應先關閉mongod
在配置檔案中添加一下選項:
replset=testset # 副本集的名稱,表示作為副本集中的節點
replindexpprefetch=id_only # 啟用副本集索引預取(非必須),隻在從節點有效
添加主機進副本集:
該主機需要監聽在能副本集中其它節點通信的套接字上
在配置檔案中設定了副本集的名稱要和目前副本集一樣
連接配接從節點進行操作:
讓副本集中主節點“下台”:觸發選舉
檢視副本集oplog的資訊:
3、選舉
副本集的重新選舉的影響條件:
心跳資訊
優先級
預設為1,0優先級不能觸發選舉過程,高優先級的節點能觸發選舉讓自己“上台”
optime
成員節點最近一次應用于本地oplog的條目的時間戳
網絡連接配接
副本集出現分區時,“多數方“才能選舉出主節點
網絡分區
同上
選舉機制:
觸發選舉的事件:
新副本集初始化時
從節點聯系不到主節點時
主節點“下台”時
主節點收到stepdown()指令時
某從節點有更高的優先級且已經滿足成主節點其它所有條件
主節點無法聯系到副本集的“多數方”
4、修改副本集節點的配置
先使用一個變量儲存目前副本集的配置:
設定節點的優先級:需要在主節點配置
添加仲裁節點:
在添加進副本集時,使用rs.addarb("hostportstr")
副本集中其它指令:
rs.freeze(secs):讓節點在指定時間内不能被選舉為主節點
rs.printslavereplicationinfo():檢視從節點是否跟上了主節點,較低版本沒有這個指令