MongoDB 2.6複製集單節點部署(三)

MongoDB在單節點中也能夠作複製集,可是僅限於測試實驗,最大的好處就是部署方便快速,能夠隨便添加新節點,節省資源。在這裏我使用的是MongoDB 2.6版本進行復制集實驗(但MongoDB配置文件使用的是老版本格式),一共使用三個節點,一個是主節點(PRIMARY),一個是從節點(SECONDARY),一個是投票節點(ARBITER)。以下圖:node

MongoDB 2.6複製集單節點部署(三)

1、實驗環境linux

1)節點信息:192.168.60.60mongodb

3)節點確保iptables和selinux已關閉shell

2、安裝MongoDB 2.6數據庫

PS:須要的軟件包能夠去http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/下載,MongoDB的安裝很簡單,怎麼安裝都成。數組

3、配置單點複製集(啓動三個套接字)架構

1)建立所須要的目錄app

2)建立三個配置文件tcp

192.168.60.60:27017ide

192.168.60.60:27018

192.168.60.60:27019

3)啓動集羣(全部節點)

查看進程

4)選擇一個節點作主節點(能夠隨意選擇一個,這裏我使用21017)

5)初始化27017節點

5.1.爲複製集初始化創建配置文檔

5.2.更新配置文檔參數,設置27019爲arbiterOnly(投票節點)

PS:上面是把複製集初始化配置文檔賦值給config變量,這裏是經過membes數組的索引來修改節點屬性,數組索引從0開始。

具體的配置文檔說明請看《MongoDB複製集配置文檔介紹》

5.3.使用rs.initiate(cfg)初始化集羣

這裏使用rs.initiate(config)初始化集羣,config文件爲咱們上面定義的。這裏的ok返回值爲1表示命令執行成功,若是爲0則表示沒有執行成功。跟Linux中的狀態值恰好相反。如今可使用rs.conf()方法返回配置文件內容。

5.4.查看集羣狀態

咱們的集羣中有三個節點,由狀態返回值能夠看出27017爲PRIMARY節點,而27018爲SECONDARY節點,而27019爲咱們設置的ARBITER節點。這裏咱們發現mongodb的角標已經變了,變成了複製集名稱加上當前節點的狀態。一樣若是登錄27018和27019會發現都發生了變化。

5.5.查看主節點local庫

這裏咱們看一下本地的local庫,每個mongod實例都有本身的local數據庫,其中存儲了複製進程所用的數據和其餘實例單獨的信息,local數據庫對於複製時不可見的,local數據庫將不會被複制。

進入到local庫能夠看到一些集合和索引文件,其中startup_log 是一個固定集合,該集合主要是用來診斷的(每一個mongod 實例向 startup_log 插入一條有關mongod實例自身和host信息的診斷信息);system.replset保存了複製集的配置文檔信息(就是咱們上面定義的config),跟rs.conf()返回的信息同樣;oplog.rs是一個存儲了oplog的固定集合,大小爲咱們在配置文件中設置的大小;slaves包含了複製集每一個節點和與其通信的最後時間戳。若是該集合過期了,咱們能夠經過刪除該節點來讓複製集自動刷新生成。

6)驗證複製集

192.168.60.60:27017插入數據

而後咱們來看一下主節點的數據目錄(MMAPV1存儲引擎爲例):

這裏咱們能夠看到,local數據庫的物理文件local.0和local.1。Mongodb默認第一個物理文件爲64M,名字爲local.0,而後依次爲local.1…N。而local數據庫的命名空間文件「local.ns」默認爲16M,前面咱們在說命令行選項的時候就說過命名空間文件,每個數據庫都會有一個命名空間NS文件,記錄當前數據庫每個物理文件,如local.0、local.1它們之間的聯繫,同時也記錄當前這個庫中每個集合裏的索引信息。

192.168.60.60:27018同步數據

咱們看到數據已經同步過來了,可是若是咱們不是經過驅動鏈接從節點的話,咱們查看數據時會報錯,說咱們不是master節點,且slaveOK=false,因此查看不了。MongoDB在數據一致性上確實下了很大的功夫啊。那麼也就是說若是從節點想查看數據就須要開啓slaveOK,而且在從節點上是沒法進行寫入操做的。

而後咱們開啓rs.slaveOk立馬就能夠查看同步的數據了。

192.168.60.60:27019投票節點

鏈接到投票節點,咱們能夠看到PRIMARY上的數據沒有同步到投票節點上來,沒有ywnds這個庫。可是這裏須要說明的是,咱們能夠看到arbiter雖然不一樣步數據可是local庫卻有system.indexes和system.replset這兩個文件。其次咱們看一下arbiter節點的數據目錄。

能夠發現咱們所說的庫物理文件的第一個文件默認大小爲64M,而命名空間文件爲16M。

4、按照功能來區分複製集成員

從上面的分析能夠看出三個節點的不一樣之處,也能夠這麼說,上面咱們是按照數據來區分不一樣的複製集節點,那麼下面咱們按照功能上來區分各個節點。先來簡單說一下各個節點狀態的不一樣所能提供的功能有哪些?

主節點(PRIMARY):默認提供讀寫服務的節點。

從節點(SECONDARY):提供讀服務的節點,但能夠提供多樣性服務,如能夠轉爲「隱藏節點」對程序不可見、轉爲「延時節點」延時複製節點、轉爲「投票節點」具備投票權但不是arbiter。

投票節點(ARBITER):ARBITER節點,無數據,僅做選舉和充當複製集節點、也稱它爲選舉節點。

5、複製集自動容災

Mongodb複製集最大的特色就是能夠自動容災,這個特性是從主從複製的架構上改變而來,簡單來講就是當複製集(3節點)中若是PRIMARY發生故障,其餘節點沒法探測到它的心跳信息時,複製集就會產生重新投票選出一個新的PRIAMRY提供服務。下面咱們來模擬一下MongoDB的自動故障轉移功能。

咱們鏈接到27017主機上,此時的27017是PRIMARY

咱們鏈接到27018主機上,此時的27018是SECONDARY

咱們鏈接到27019主機上,此時的27019是ARBITER

模擬主節點宕機,kill掉27017的進程。

而後登陸27018主機上,看看此時的SECONDARY已經轉爲PRIMARY了,可是這個過程會有短暫的斷開。

而27019主機上ARBITER仍是ARBITER節點。

有興趣能夠經過show log rs命令查看複製集的日誌信息,看看這個過程是怎麼進行的。這就是MongoDB三節點(一主一從一投票或一主二從)複製集的故障轉移功能,是否是很強大。固然除了複製集內部自動選舉以外,咱們也能夠進行人工干預,使用rs.stepdown()方法能夠手動切換。

相關文章
相關標籤/搜索