本博主配置好的Centos7下MongoDB308-Replica Sets（複製集）Sharding（分片）Cluster集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1knkcRzBkfD76_qWO4UiuLg
提取碼：v5nt 下載後，用Vmware Workstation即可以打開，使用
mongodb 不推薦主從複製,推薦建立副本集(Replica
1）關於副本集的概念
副本集是一種在多台機器同步數據的進程，副本集體提供了數據冗餘，擴展了數據可用性。在多台服務器保存數據可以避免因為一台服務器導致的數據丟失。
也可以從硬件故障或服務中斷解脫出來，利用額外的數據副本，可以從一台機器致力於災難恢復或者備份。
在一些場景，可以使用副本集來擴展讀性能，客戶端有能力發送讀寫操作給不同的服務器。也可以在不同的數據中心獲取不同的副本來擴展分布式應用的能力。
mongodb副本集是一組擁有相同數據的mongodb實例，主mongodb接受所有的寫操作，所有的其他實例可以接受主實例的操作以保持數據同步。
主實例接受客戶的寫操作，副本集只能有一個主實例，因為為了維持數據一致性，只有一個實例可寫，主實例的日誌保存在oplog。
Client Application Driver
Writes Reads
| |
Primary
|Replication|Replication
Secondary Secondary
二級節點複製主節點的oplog然後在自己的數據副本上執行操作，二級節點是主節點數據的反射，如果主節點不可用，會選舉一個新的主節點。
默認讀操作是在主節點進行的，但是可以指定讀取首選項參數來指定讀操作到副本節點。
可以添加一個額外的仲裁節點（不擁有被選舉權），使副本集節點保持奇數，確保可以選舉出票數不同的直接點。仲裁者並不需要專用的硬件設備。
仲裁者節點一直會保存仲裁者身份
……..異步複製……..
副本節點同步直接點操作是異步的，然而會導致副本集無法返回最新的數據給客戶端程序。
……..自動故障轉移……..
如果主節點10s以上與其他節點失去通信，其他節點將會選舉新的節點作為主節點。
擁有大多數選票的副節點會被選舉為主節點。
副本集提供了一些選項給應用程序，可以做一個成員位於不同數據中心的副本集。
也可以指定成員不同的優先級來控制選舉。
2）副本集的結構及原理
MongoDB 的副本集不同於以往的主從模式。
在集群Master故障的時候,副本集可以自動投票,選舉出新的Master,並引導其餘的Slave服務器連接新的Master,而這個過程對於應用是透明的。可以說MongoDB的副本集
是自帶故障轉移功能的主從複製。
相對於傳統主從模式的優勢
傳統的主從模式,需要手工指定集群中的 Master。如果 Master 發生故障,一般都是人工介入,指定新的 Master。 這個過程對於應用一般不是透明的,往往伴隨着應用重
新修改配置文件,重啟應用服務器等。而 MongoDB 副本集,集群中的任何節點都可能成為 Master 節點。一旦 Master 節點故障,則會在其餘節點中選舉出一個新的 Master 節點。 並引導剩餘節點連接到新的 Master 節點。這個過程對於應用是透明的。
一個副本集即為服務於同一數據集的多個 MongoDB 實例,其中一個為主節點,其餘的都為從節點。主節 點上能夠完成讀寫操作,從節點僅能用於讀操作。主節點需要記錄所有改變數據庫狀態的操作,這些記錄 保存在 oplog 中,這個文件存儲在 local 數據庫,各個從節點通過此 oplog 來複制數據並應用於本地,保持 本地的數據與主節點的一致。oplog 具有冪等性,即無論執行幾次其結果一致,這個比 mysql 的二進制日 志更好用。
集群中的各節點還會通過傳遞心跳信息來檢測各自的健康狀況。當主節點故障時,多個從節點會觸發一次 新的選舉操作,並選舉其中的一個成為新的主節點(通常誰的優先級更高,誰就是新的主節點),心跳信 息默認每 2 秒傳遞一次。
客戶端連接到副本集後，不關心具體哪一台機器是否掛掉。主服務器負責整個副本集的讀寫，副本集定期同步數據備份。一旦主節點掛掉，副本節點就會選舉一個新的主服務器。這一切對於應用服務器不需要關心。
心跳檢測：
整個集群需要保持一定的通信才能知道哪些節點活着哪些節點掛掉。mongodb節點會向副本集中的其他節點每兩秒就會發送一次pings包，如果其他節點在10秒鐘
之內沒有返回就標示為不能訪問。每個節點內部都會維護一個狀態映射表，表明當前每個節點是什麼角色、日誌時間戳等關鍵信息。如果是主節點，除了維護映射表
外還需要檢查自己能否和集群中內大部分節點通訊，如果不能則把自己降級為secondary只讀節點。
數據同步
副本集同步分為初始化同步和keep複製。初始化同步指全量從主節點同步數據，如果主節點數據量比較大同步時間會比較長。而keep複製指初始化同步過後，節點
之間的實時同步一般是增量同步。初始化同步不只是在第一次才會被處罰，有以下兩種情況會觸發：
1）secondary第一次加入，這個是肯定的。
2）secondary落後的數據量超過了oplog的大小，這樣也會被全量複製。
副本集中的副本節點在主節點掛掉後通過心跳機制檢測到後，就會在集群內發起主節點的選舉機制，自動選舉出一位新的主服務器。
副本集包括三種節點:主節點、從節點、仲裁節點。本博主配置好的Centos7下MongoDB308-Replica Sets（複製集）Sharding（分片）Cluster集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1knkcRzBkfD76_qWO4UiuLg
提取碼：v5nt 下載後，用Vmware Workstation即可以打開，使用
1）主節點負責處理客戶端請求,讀、寫數據, 記錄在其上所有操作的 oplog;
2）從節點定期輪詢主節點獲取這些操作,然後對自己的數據副本執行這些操作,從而保證從節點的數據與主節點一致。默認情況下,從節點不支持外部讀取,但可以設置;
副本集的機制在於主節點出現故障的時候,餘下的節點會選舉出一個新的主節點,從而保證系統可以正常運行。
3）仲裁節點不複製數據,僅參與投票。由於它沒有訪問的壓力,比較空閑,因此不容易出故障。由於副本集出現故障的時候,存活的節點必須大於副本集節點總數的一半,
否則無法選舉主節點,或者主節點會自動降級為從節點,整個副本集變為只讀。因此,增加一個不容易出故障的仲裁節點,可以增加有效選票,降低整個副本集不可用的
風險。仲裁節點可多於一個。也就是說只參與投票，不接收複製的數據，也不能成為活躍節點。
官方推薦MongoDB副本節點最少為3台， 建議副本集成員為奇數，最多12個副本節點,最多7個節點參與選舉。限制副本節點的數量,主要是因為一個集群中過多的副本節點,增加了複製的成本,反而拖累了集群
的整體性能。 太多的副本節點參與選舉,也會增加選舉的時間。而官方建議奇數的節點,是為了避免腦裂 的發生。
3）副本集的工作流程
在 MongoDB 副本集中,主節點負責處理客戶端的讀寫請求,備份節點則負責映射主節點的 數據。備份節點的工作原理過程可以大致描述為,備份節點定期輪詢主節點上的數據操作,
然後對 自己的數據副本進行這些操作,從而保證跟主節點的數據同步。至於主節點上的所有 數據庫狀態改變 的操作,都會存放在一張特定的系統表中。備份節點則是根據這些數據進
行自己的數據更新。
oplog
上面提到的數據庫狀態改變的操作,稱為 oplog(operation log,主節點操作記錄)。oplog 存儲在 local 數據庫的”oplog.rs”表中。副本集中備份節點異步的從主節點同步 oplog,然後重新 執行它記錄的操作,以此達到了數據同步的作用。
關於 oplog 有幾個注意的地方:
1）oplog 只記錄改變數據庫狀態的操作
2）存儲在 oplog 中的操作並不是和主節點執行的操作完全一樣,例如”$inc”操作就會轉化為”$set”操作
3）oplog 存儲在固定集合中(capped collection),當 oplog 的數量超過 oplogSize,新的操作就會覆蓋就的操作
數據同步
在副本集中,有兩種數據同步方式:
1）initial sync(初始化):這個過程發生在當副本集中創建一個新的數據庫或其中某個節點剛從宕機中恢復,或者向副本集中添加新的成員的時候,默認的,副本集中的節點會從離 它最近
的節點複製 oplog 來同步數據,這個最近的節點可以是 primary 也可以是擁有最新 oplog 副本的 secondary 節點。該操作一般會重新初始化備份節點,開銷較大。
2）replication(複製):在初始化後這個操作會一直持續的進行着,以保持各個 secondary 節點之間的數據同步。
initial sync
當遇到無法同步的問題時,只能使用以下兩種方式進行 initial sync 了
1）第一種方式就是停止該節點,然後刪除目錄中的文件,重新啟動該節點。這樣,這個節 點就會執行 initial sync
注意:通過這種方式,sync 的時間是根據數據量大小的,如果數據量過大,sync 時間就 會很長
同時會有很多網絡傳輸,可能會影響其他節點的工作
2）第二種方式,停止該節點,然後刪除目錄中的文件,找一個比較新的節點,然後把該節點目 錄中的文件拷貝到要 sync 的節點目錄中
通過上面兩種方式中的一種,都可以重新恢復”port=33333″的節點。不在進行截圖了。
副本集管理
1）查看oplog的信息 通過”db.printReplicationInfo()”命令可以查看 oplog 的信息
字段說明:
configured oplog size: oplog 文件大小
log length start to end: oplog 日誌的啟用時間段
oplog first event time: 第一個事務日誌的產生時間
oplog last event time: 最後一個事務日誌的產生時間
now: 現在的時間
2）查看 slave 狀態 通過”db.printSlaveReplicationInfo()”可以查看 slave 的同步狀態
當插入一條新的數據,然後重新檢查 slave 狀態時,就會發現 sync 時間更新了
4）副本集選舉的過程和注意點
Mongodb副本集選舉採用的是Bully算法，這是一種協調者(主節點)競選算法,主要思想是集群的每個成員都可以聲明它是主節點並通知其他節點。
別的節點可以選擇接受這個聲稱或是拒絕並進入主節點競爭，被其他所有節點接受的節點才能成為主節點。
節點按照一些屬性來判斷誰應該勝出，這個屬性可以是一個靜態 ID,也可以是更新的度量像最近一次事務ID(最新的節點會勝出)
副本集的選舉過程大致如下:
1）得到每個服務器節點的最後操作時間戳。每個 mongodb 都有 oplog 機制會記錄本機的操作,方便和主服 務器進行對比數據是否同步還可以用於錯誤恢復。
2）如果集群中大部分服務器 down 機了,保留活着的節點都為 secondary 狀態並停止,不選舉了。
3）如果集群中選舉出來的主節點或者所有從節點最後一次同步時間看起來很舊了,停止選舉等待人來操作。
4）如果上面都沒有問題就選擇最後操作時間戳最新(保證數據是最新的)的服務器節點作為主節點。本博主配置好的Centos7下MongoDB308-Replica Sets（複製集）Sharding（分片）Cluster集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1knkcRzBkfD76_qWO4UiuLg
提取碼：v5nt 下載後，用Vmware Workstation即可以打開，使用
副本集選舉的特點：
選舉還有個前提條件,參與選舉的節點數量必須大於副本集總節點數量的一半（建議副本集成員為奇數。最多12個副本節點,最多7個節點參與選舉）
如果已經小於一半了所有節點保持只讀狀態。集合中的成員一定要有大部分成員(即超過一半數量)是保持正常在線狀態,3個成員的副本集,需要至少2個從屬節點是正常狀態。
如果一個從屬節點掛掉,那麼當主節點down掉 產生故障切換時,由於副本集中只有一個節點是正常的,少於一半,則選舉失敗。
4個成員的副本集,則需要3個成員是正常狀態(先關閉一個從屬節點,然後再關閉主節點,產生故障切換,此時副本集中只有2個節點正常,則無法成功選舉出新主節點)。
5）副本集數據過程
Primary節點寫入數據，Secondary通過讀取Primary的oplog得到複製信息，開始複製數據並且將複製信息寫入到自己的oplog。如果某個操作失敗，則備份節點
停止從當前數據源複製數據。如果某個備份節點由於某些原因掛掉了，當重新啟動後，就會自動從oplog的最後一個操作開始同步，同步完成後，將信息寫入自己的
oplog，由於複製操作是先複製數據，複製完成後再寫入oplog，有可能相同的操作會同步兩份，不過MongoDB在設計之初就考慮到這個問題，將oplog的同一個操作
執行多次，與執行一次的效果是一樣的。簡單的說就是：
當Primary節點完成數據操作後，Secondary會做出一系列的動作保證數據的同步：
1）檢查自己local庫的oplog.rs集合找出最近的時間戳。
2）檢查Primary節點local庫oplog.rs集合，找出大於此時間戳的記錄。
3）將找到的記錄插入到自己的oplog.rs集合中，並執行這些操作。
副本集的同步和主從同步一樣，都是異步同步的過程，不同的是副本集有個自動故障轉移的功能。其原理是：slave端從primary端獲取日誌，然後在自己身上完全順序
的執行日誌所記錄的各種操作（該日誌是不記錄查詢操作的），這個日誌就是local數據 庫中的oplog.rs表，默認在64位機器上這個表是比較大的，占磁盤大小的5%，
oplog.rs的大小可以在啟動參數中設 定：–oplogSize 1000,單位是M。
注意：在副本集的環境中，要是所有的Secondary都宕機了，只剩下Primary。最後Primary會變成Secondary，不能提供服務。
Sharding cluster是一種可以水平擴展的模式,在數據量很大時特給力,實際大規模應用一般會採用這種架構去構建。sharding分片很好的解決了單台服務器磁盤空間、內存、cpu等硬件資源的限制問題，把數據水平拆分出去，降低單節點的訪問壓力。每個分片都是一個獨立的數據庫，所有的分片組合起來構成一個邏輯上的完整的數據庫。因此，分片機制降低了每個分片的數據操作量及需要存儲的數據量，達到多台服務器來應對不斷增加的負載和數據的效果。
1）Sharding分區概念
分片 (sharding)是指將數據庫拆分,將其分散在不同的機器上的過程。將數據分散到不同的機器上,不需要功能強大的服務器就可以存儲更多的數據和處理更大的負載。
分片的基本思想就是：
將集合切成小塊,這些塊分散到若干片里,每個片只負責總數據的一部分。通過一個名為 mongos 的路由進程進行操作,mongos 知道數據和片的對應
關係(通過配置服務器)。 大部分使用場景都是解決磁盤空間的問題,對於寫入有可能會變差(+++裡面的說明+++),查 詢則盡量避免跨分片查詢。使用分片的時機:
使用場景：
1）機器的磁盤不夠用了。使用分片解決磁盤空間的問題。
2）單個mongod已經不能滿足寫數據的性能要求。通過分片讓寫壓力分散到各個分片上面,使用分片服務器自身的資源。
3）想把大量數據放到內存里提高性能。和上面一樣,通過分片使用分片服務器自身的資源。
要構建一個MongoDB Sharding Cluster（分片集群）,需要三種角色:
1）分片服務器（Shard Server）
mongod 實例,用於存儲實際的數據塊,實際生產環境中一個 shard server 角色可由幾台機器組個一個 relica set 承擔,防止主機單點故障
這是一個獨立普通的mongod進程,保存數據信息。可以是一個副本集也可以是單獨的一台服務器。
2）配置服務器（Config Server）
mongod 實例,存儲了整個 Cluster Metadata,其中包括 chunk 信息。
這是一個獨立的mongod進程,保存集群和分片的元數據,即各分片包含了哪些數據的信息。最先開始建立,啟用日誌功能。像啟動普通的 mongod 一樣啟動
配置服務器,指定configsvr 選項。不需要太多的空間和資源,配置服務器的 1KB 空間相當於真是數據的 200MB。保存的只是數據的分布表。
3）路由服務器（Route Server）
mongos實例,前端路由,客戶端由此接入,且讓整個集群看上去像單一數據庫,前端應用
起到一個路由的功能,供程序連接。本身不保存數據,在啟動時從配置服務器加載集群信息,開啟 mongos 進程需要知道配置服務器的地址,指定configdb選項。
本博主配置好的Centos7下MongoDB308-Replica Sets（複製集）Sharding（分片）Cluster集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1knkcRzBkfD76_qWO4UiuLg
提取碼：v5nt 下載後，用Vmware Workstation即可以打開，使用
片鍵的意義
一個好的片鍵對分片至關重要。 片鍵必須是一個索引 ,通 過 sh.shardCollection 加會自動創建索引。一個自增的片鍵對寫入和數據均勻分布就不是很好, 因為自增
的片鍵總會在一個分片上寫入,後續達到某個閥值可能會寫到別的分片。但是按照片鍵查詢會非常高效。隨機片鍵對數據的均勻分布效果很好。注意盡量避免在多個分片上進行查詢。
在所有分片上查詢,mongos 會對結果進行歸併排序
為何需要水平分片
1）減少單機請求數,將單機負載,提高總負載
2）減少單機的存儲空間,提高總存空間
mongodb sharding 服務器架構
簡單註解:
分片集群主要由三種組件組成:mongos,config server,shard
1) mongos (路由進程, 應用程序接入 mongos 再查詢到具體分片)
數據庫集群請求的入口,所有的請求都通過 mongos 進行協調,不需要在應用程序添加一個路由選擇器,mongos 自己就是一個請求分發中心,它負責把對應的數據請求
請求轉發到對應的 shard 服務器上。在生產環境通常有多個 mongos 作為請求的入口,防止其中一個掛掉所有的 mongodb 請求都沒有辦法操作。
2) config server (路由表服務。 每一台都具有全部 chunk 的路由信息)
顧名思義為配置服務器,存儲所有數據庫元信息(路由、分片)的配置。mongos 本身沒有物理存儲分片服務器和數據路由信息,只是緩存在內存里,配置服務器則實際存儲
這些數據。mongos 第一次啟動或者關掉重啟就會從 config server 加載配置信息,以後如果配置服務器信息變化會通知到所有的 mongos 更新自己的狀態,這樣
mongos 就能繼續準確路由。在生產環境通常有多個 config server 配置服務器,因為它存儲了分片路由的元數據,這個可不能丟失!就算掛掉其中一台,只要還有存貨,
mongodb 集群就不會掛掉。
3) shard (為數據存儲分片。 每一片都可以是複製集(replica set))
這就是傳說中的分片了。如圖所示,一台機器的一個數據表 Collection1 存儲了 1T 數據,壓力太大了!在分給 4 個機器後, 每個機器都是 256G,則分攤了集中在一台
機器的壓力。事實上,上圖4個分片如果沒有副本集(replica set)是個不完整架構,假設其中的一個分片掛掉那四 分之一的數據就丟失了,所以在高可用性的分片架構還
需要對於每一個分片構建 replica set 副本集保 證分片的可靠性。生產環境通常是 2 個副本 + 1 個仲裁。
2）Sharding分區的原理
分片,是指將數據拆分,將其分散到不同的機器上。這樣的好處就是,不需要功能強大的大型計算機也可以存儲更多的數據,處理更大的負載。mongoDB 的分片,
是將collection 的數據進行分割,然後將不同的部分分別存儲到不同的機器上。當 collection 所佔空間過大時,我們需要增加一台新的機器,分片會自動
將 collection 的數據分發到新的機器上。
mongoDB sharding分片的原理
人臉：
代表客戶端，客戶端肯定說，你數據庫分片不分片跟我沒關係，我叫你幹啥就幹啥，沒什麼好商量的。
mongos：
首先我們要了解”片鍵“的概念，也就是說拆分集合的依據是什麼？按照什麼鍵值進行拆分集合。mongos就是一個路由服務器，它會根據管理員設置的”片鍵”
將數據分攤到自己管理的mongod集群，數據和片的對應關係以及相應的配置信息保存在”config服務器”上。
客戶端只需要對 mongos 進行操作就行了,至於如何進行分片,不需要 客戶端參與,由 mongos 和 config 來完成。
mongod:
一個普通的數據庫實例或者副本集，如果不分片的話，我們會直接連上mongod。
分片是指將數據拆分,將其分散存在不同機器上的過程.有時也叫分區.將數據分散在不同的機器上MongoDB支持自動分片,可以擺脫手動分片的管理.集群自動切分數據,做負載均衡
分片集群的構造如下：
分片集群由以下3個服務組成：
Shards Server: 每個shard由一個或多個mongod進程組成，用於存儲數據
Config Server: 用於存儲集群的Metadata信息，包括每個Shard的信息和chunks信息
Route Server: 用於提供路由服務，由Client連接，使整個Cluster看起來像單個DB服務器
本博主配置好的Centos7下MongoDB308-Replica Sets（複製集）Sharding（分片）Cluster集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1knkcRzBkfD76_qWO4UiuLg
提取碼：v5nt 下載後，用Vmware Workstation即可以打開，使用
以下文章點擊率最高
Loading…