配置副本集成員是通過哪個節點

『壹』 搭建MongoDB副本集&分片

顧名思義，副本集是一個集合，即MongoDB實例的集合，集合中的每個成員擁有相同的數據集合；一個副本集包含多個數據節點和一個可選的仲裁節點，在數據節點中，只有一個可以作為主節點（Primary Node），其他節點只能是第二節點（Secondary Nodes）。
主節點接收所有的寫操作，一個副本集只能有一個能夠確認寫入的主節點（Primary Node），如下圖：

第二節點復制主節點的操作日誌並且將所有的操作應用到自己的數據集合中，復制過程是非同步的，如果主節點不可用，一個可以被選舉的第二節點將會被選舉為主節點，所以在副本集中，即使一個或者多個成員沒有正常運行，但整個副本集仍然可以正常工作；主副節點關系如下圖：

在某些情況下（比如受硬體條件所限，只有一個主節點和一個副節點，無法添加更多的副節點），你可以選擇將mongod實例添加進副本集，並作為仲裁者（仲裁者只負責選舉新的主節點，不持有數據），在副本集中，如果主節點與其他節點無法通信的時間超過配置的時間值( electionTimeoutMillis )，那麼副本集將視主節點出現故障，此時將會重新選舉一個正常副節點來作為新的主節點，從而讓整個副本集系統正常工作，如下圖：

副本集的搭建的步驟為：同時啟動多個mongod實例（可以在一台伺服器上，也可以在不同的伺服器上），然後在每個實例的配置文件中配置相應的配置項，最後啟動實例後，登錄並且在做一次配置即可。

注意: 文中都是通過配置文件的方式來啟動mongod實例的，你也可以通過啟動參數來啟動實例，同時本文中的mongod實例是通過 supervisor 來管理的，關於如何通過supervisor管理進程，可以自行查閱相關資料或者參考 這里

對於每一個配置項，如果不明白每個配置項的釋義，請參考: mongo配置文件 。另外，如果實例在同一台機器上，則針對每個實例，需要區分 path , pidFilePath , port , dbPath 這幾個的配置值，並且每個配置文件中的 replSetName 必須相同。

在supervisorctl中執行update，此時三個實例便啟動成功。

分片是將MongoDB中的數據集分割成多個數據片，每片數據存放在不同的MongoDB實例中，可以理解為將一個MongoDB數據集拆分成多個小型數據集，而小數據集分布在相同或者不同的物理機器上，分割只是從物理層面進行分割，邏輯上仍然屬於同一個數據集合。

分片包含三部分, 如下圖所示:

注意: 不同的分片集群必須使用不同的配置伺服器(Config Servers)，不能使用同一個配置伺服器(Config Servers)

分片實例的搭建與副本集類似，都是配置不同的配置文件，然後啟動相應的實例:

這里只給出了關鍵配置項，其他配置項根據自己的實際情況配置，圖中的 replSetName 表示當前實例屬於哪個副本集，該副本集中的每個節點的該配置項必須一致， clusterRole 表示當前節點在分片中的的角色，可選值有: shardsvr 和 configsvr ， shardsvr 表示該節點是作為Shards節點提供服務，而 configsvr 表示該節點作為Config Server節點提供服務。

至此，分片搭建完成。

『貳』 MongoDB分片集群搭建

分片（sharding）是一種跨多台機器分布數據的方法，MongoDB使用分片來支持具有非常大的數據集和高吞吐量操作的部署。換句話說：分片就是將數據拆分，將其分散存在不同的機器上的過程，將數據分散到不同的機器上，不需要功能強大的大型計算機就可以存儲更多的數據，處理更多的負載。

MongoDB分片集群包含以下組件：

下圖描述了分片集群中組件的交互：

本文搭建的副本集集群是兩個分片節點副本集（3+3）+一個配置節點副本集（3）+兩個路由節點（2），共11個服務節點，具體如下圖所示：

本次搭建一主一副本一仲裁，相關的配置文件、數據、日誌都放在sharded_cluster相應的子目錄下面，具體步驟如下：

myshardrs01

設置sharding.clusterRole需要mongod實例運行復制。 要將實例部署為副本集成員，請使用
replSetName設置並指定副本集的名稱。

使用客戶端命令連接主節點，這里最好連接主節點

執行初始化副本集命令：

查看副本集情況：

同樣搭建一主一副本一仲裁，相關的配置文件、數據、日誌都放在sharded_cluster相應的子目錄下面，
具體步驟如下：

myshardrs02

myshardrs01_27318

設置sharding.clusterRole需要mongod實例運行復制。 要將實例部署為副本集成員，請使用
replSetName設置並指定副本集的名稱

myshardrs01_27418

myshardrs01_27518

啟動第二套副本集：一主一副本一仲裁

依次啟動三個mongod服務：

查看服務是否啟動：

新建或修改配置文件：
myconfigrs_27019：

新建或修改配置文件：
myconfigrs_27119

新建或修改配置文件：
myconfigrs_27219

依次啟動配置的mongod副本集：一主兩副本

查看服務是否啟動：

『叄』 mongodb--選舉失敗

mongodb搭建了一個集群 測試的只有兩個節點
為了測試副本集群的自動切換

關閉了主節點 但是發現子節點許可權為只讀 沒有成為主節點

https://www.modb.pro/db/53381 參考了這篇文章 得知

例如：有N個副本集成員節點，必須有N/2+1個成員投票支持某個節點，此節點才能成為主節點。注意：副本集中若有成員節點處於不可用狀態，並不會影響副本集中的「大多數」，「大多數」是以副本集的配置來計算的。

2/2+1=2 也就是必須有兩個節點投票支持 才能成為主節點！

『肆』 linux安裝MongoDB雙機熱備份（主從復制）

主從復製作用：數據備份、讀寫分離
雙機熱備份：部署兩個節點的MongoDB服務，配置一主一從，主節點添加數據，將自動備份到從節點上面，保證主機宕機後數據不丟失，同時可以繼續提供數據讀取服務(主服務掛掉，從服務將無法在進行寫入數據，只能提供數據讀取服務)
一主多從：部署多個節點的MongoDB服務，配置一主多從，數據也會自動備份到所有從節點上面，保證主機宕機後數據不丟失，同時可以根據從節點的優先順序進行選取新的主節點，繼續提供讀寫服務（主從關系跟服務設置的優先順序有直接關系 優先順序參數：priority 數字越大優先順序越高）

使用上面的方式，在不同伺服器上安裝並啟動MongoDB服務

將啟動時使用的配置文件mongodb.conf中添加下面的副文本集名稱配置，將許可權控制參數改為false（auth=false），然後將服務進行重新啟動即可（testrs是自定義的副本集名稱）
#使用此設置來配置復制副本集。指定一個副本集名稱作為參數，所有主機都必須有相同的名稱作為同一個副本集
replSet=testrs

然後啟動每個服務的客戶端查看當前節點為主節點還是從節點；
1). 如果服務部署在不同伺服器上，直接啟動/bin目錄下的mongo即可 命令：./ mongo
2). 如果服務部署在同一台伺服器上，使用不同埠及配置文件進行啟動的，啟動客戶端使用該命令 命令：./mongo 127.0.0.1:27018/

經過上面的一系列操作後，主從配置就完成了，接下來可以進行數據同步測試

第一步：在主庫上面切換到admin，然後進行添加數據（命令：db.testdb1.insert([{"name":"zs"}])）

在從庫上查詢該數據（命令：db.testdb1.find({name:"zs"})），會出現下面如圖的錯誤，因為從庫沒有查詢數據許可權，所以需要設置查詢許可權

設置從庫查詢許可權，使用命令：rs.secondaryOk()
然後在使用查詢命令進行查詢（命令：db.testdb1.find({name:"zs"})）就會看到如下圖的查詢結果：

如上圖所示，數據已經同步到從庫上面了，這樣雙機熱備份就已經實現了，上面的情況不包含許可權控制

上面的情況已經完成了MongoDB的主從復制功能，但是我們把許可權沒有開放，啟動時使用的配置中auth配置的值為false，說明沒有添加許可權，接下來就開放一下許可權配置；
首先需要主從之間通信的一個keyFile文件，根據官網提供的說明，這個keyfile是可以任意內容的，只要保證所有集群中的機器都擁有同樣的文件即可。

我這里將keyFile文件放到了MongoDB的bin目錄下了，使用openssl rand -base64 1024 > /usr/local/mongodb-master/bin/mongodb.key 命令生成；

然後將mongodb.key文件復制到每台從服務上面，在每台服務的啟動文件上添加 keyFile=/usr/local/mongodb-master/keyfile/mongodb.key 配置項 ，然後將auth屬性值改為true，這樣就完成了許可權配置

重啟主從兩個節點，這樣主機添加的數據，就會同步到從機上面了！！！

添加或刪除從節點參考文章：
https://blog.csdn.net/weixin_44839444/article/details/105666163

『伍』 MongoDB副本集同步原理解析

在MongoDB的副本集中，節點之間是通過oplog來同步數據。Primary節點每執行一次數據寫入，都會記錄一條oplog，Secondary節點會持續不斷的自Primary拉取oplog並在本地回放，從而確保各節點達到數據最終一致性。

Primary節點並發寫入數據，時間點分別為t1、t2和t3，按時間先後排序為 t1 -> t2 -> t3；如果t1和t3先落庫，t2後落庫，那麼在oplog集合中如何能保證有序呢？

MongoDB底層通用的存儲引擎為WiredTiger、In-Memory，以WiredTiger為例，MongoDB管理層調用WiredTiger引擎介面向oplog集合中插入文檔（即記錄）；

WiredTiger會以 oplog 的 ts 欄位作為 key、文檔內容作為 value，寫入一條 KV 記錄，wiredtiger 會保證存儲（btree 或 lsm 的方式都能保證）的文檔按 key 來排序，這樣就解決 「Primary節點oplog如何保證有序」 的問題；

並發寫入多條oplog ts1、ts2、ts3和ts4，其中 ts1<ts2<ts3<ts4，如果ts1、ts2和ts4先寫入primary成功，ts3存在延遲，還未寫入，此時secondary節點自pirmary拉取oplog在本地回放，如何保證有序呢？

MongoDB（wiredtiger 引擎）的解決方案是在讀取oplog時進行限制，保證Secondary 節點看到一定是順序的，具體實現機制如下：

如此既可以確保 「secondary節點在本地回放oplog時有序」

Secondary節點回放oplog在保證有序的前提下，如何保證高效呢？如下：

如果OpQueue隊列中的oplog有對同一個collection的操作，後續並發進行數據回放時，如何保證同一個collections中兩條oplog的執行順序呢？

參考文檔：
MongoDB 如何保證 oplog 順序？
MongoDB復制集同步原理解析

『陸』 MongoDB是什麼，怎麼用看完你就知道了

MongoDB是一款為web應用程序和互聯網基礎設施設計的資料庫管理系統。沒錯MongoDB就是資料庫，是Nosql類型的資料庫。

（1）MongoDB提出的是文檔、集合的概念，使用BSON（類JSON）作為其數據模型結構，其結構是面向對象的而不是二維表，存儲一個用戶在MongoDB中是這樣子的。

使用這樣的數據模型，使得MongoDB能在生產環境中提供高讀寫的能力，吞吐量較於mysql等SQL資料庫大大增強。

（2）易伸縮，自動故障轉移。易伸縮指的是提供了分片能力，能對數據集進行分片，數據的存儲壓力分攤給多台伺服器。自動故障轉移是副本集的概念，MongoDB能檢測主節點是否存活，當失活時能自動提升從節點為主節點，達到故障轉移。

（3）數據模型因為是面向對象的，所以可以表示豐富的、有層級的數據結構，比如博客系統中能把「評論」直接懟到「文章「的文檔中，而不必像myqsl一樣創建三張表來描述這樣的關系。

（1）文檔數據類型

SQL類型的資料庫是正規化的，可以通過主鍵或者外鍵的約束保證數據的完整性與唯一性，所以SQL類型的資料庫常用於對數據完整性較高的系統。MongoDB在這一方面是不如SQL類型的資料庫，且MongoDB沒有固定的Schema，正因為MongoDB少了一些這樣的約束條件，可以讓數據的存儲數據結構更靈活，存儲速度更加快。

（2）即時查詢能力

MongoDB保留了關系型資料庫即時查詢的能力，保留了索引（底層是基於B tree）的能力。這一點汲取了關系型資料庫的優點，相比於同類型的NoSQL redis 並沒有上述的能力。

（3）復制能力

MongoDB自身提供了副本集能將數據分布在多台機器上實現冗餘，目的是可以提供自動故障轉移、擴展讀能力。

（4）速度與持久性

MongoDB的驅動實現一個寫入語義 fire and forget ，即通過驅動調用寫入時，可以立即得到返回得到成功的結果（即使是報錯），這樣讓寫入的速度更加快，當然會有一定的不安全性，完全依賴網路。

MongoDB提供了Journaling日誌的概念，實際上像mysql的bin-log日誌，當需要插入的時候會先往日誌裡面寫入記錄，再完成實際的數據操作，這樣如果出現停電，進程突然中斷的情況，可以保障數據不會錯誤，可以通過修復功能讀取Journaling日誌進行修復。

（5）數據擴展

MongoDB使用分片技術對數據進行擴展，MongoDB能自動分片、自動轉移分片裡面的數據塊，讓每一個伺服器裡面存儲的數據都是一樣大小。

MongoDB核心伺服器主要是通過mongod程序啟動的，而且在啟動時不需對MongoDB使用的內存進行配置，因為其設計哲學是內存管理最好是交給操作系統，缺少內存配置是MongoDB的設計亮點，另外，還可通過mongos路由伺服器使用分片功能。

MongoDB的主要客戶端是可以交互的js shell 通過mongo啟動，使用js shell能使用js直接與MongoDB進行交流，像使用sql語句查詢mysql數據一樣使用js語法查詢MongoDB的數據，另外還提供了各種語言的驅動包，方便各種語言的接入。

mongomp和mongorestore,備份和恢復資料庫的標准工具。輸出BSON格式，遷移資料庫。

mongoexport和mongoimport，用來導入導出JSON、CSV和TSV數據，數據需要支持多格式時有用。mongoimport還能用與大數據集的初始導入，但是在導入前順便還要注意一下，為了能充分利用好mongoDB通常需要對數據模型做一些調整。

mongosniff,網路嗅探工具，用來觀察發送到資料庫的操作。基本就是把網路上傳輸的BSON轉換為易於人們閱讀的shell語句。

因此，可以總結得到，MongoDB結合鍵值存儲和關系資料庫的最好特性。因為簡單，所以數據極快，而且相對容易伸縮還提供復雜查詢機制的資料庫。MongoDB需要跑在64位的伺服器上面，且最好單獨部署，因為是資料庫，所以也需要對其進行熱備、冷備處理。

因為本篇文章不是API手冊，所有這里對shell的使用也是基礎的介紹什麼功能可以用什麼語句，主要是為了展示使用MongoDB shell的方便性，如果需要知道具體的MongoDB shell語法可以查閱官方文檔。

創建資料庫並不是必須的操作，資料庫與集合只有在第一次插入文檔時才會被創建，與對數據的動態處理方式是一致的。簡化並加速開發過程，而且有利於動態分配命名空間。如果擔心資料庫或集合被意外創建，可以開啟嚴格模式。

以上的命令只是簡單實例，假設如果你之前沒有學習過任何資料庫語法，同時開始學sql查詢語法和MongoDB 查詢語法，你會發現哪一個更簡單呢？如果你使用的是java驅動去操作MongoDB，你會發現任何的查詢都像Hibernate提供出來的查詢方式一樣，只要構建好一個查詢條件對象，便能輕松查詢（接下來會給出示例），博主之前熟悉ES6，所以入手MongoDB js shell完成沒問題，也正因為這樣簡潔，完善的查詢機制，深深的愛上了MongoDB。

使用java驅動鏈接MongoDB是一件非常簡單的事情，簡單的引用，簡單的做增刪改查。在使用完java驅動後我才發現spring 對MongoDB 的封裝還不如官方自身提供出來的東西好用，下面簡單的展示一下使用。

這里只舉例了簡單的鏈接與簡單的MongoDB操作，可見其操作的容易性。使用驅動時是基於TCP套接字與MongoDB進行通信的，如果查詢結果較多，恰好無法全部放進第一伺服器中，將會向伺服器發送一個getmore指令獲取下一批查詢結果。

插入數據到伺服器時間，不會等待伺服器的響應，驅動會假設寫入是成功的，實際是使用客戶端生成對象id，但是該行為可以通過配置配置，可以通過安全模式開啟，安全模式可以校驗伺服器端插入的錯誤。

要清楚了解MongoDB的基本數據單元。在關系型資料庫中有帶列和行的數據表。而MongoDB數據的基本單元是BSON文檔，在鍵值中有指向不定類型值的鍵，MongoDB擁有即時查詢，但不支持聯結操作，簡單的鍵值存儲只能根據單個鍵來獲取值，不支持事務，但支持多種原子更新操作。

如讀寫比是怎樣的，需要何種查詢，數據是如何更新的，會不會存在什麼並發問題，數據結構化的程度是要求高還是低。系統本身的需求決定mysql還是MongoDB。

在關於schema 的設計中要注意一些原則，比如：

資料庫是集合的邏輯與物理分組，MongoDB沒有提供創建資料庫的語法，只有在插入集合時，資料庫才開始建立。創建資料庫後會在磁碟分配一組數據文件，所有集合、索引和資料庫的其他元數據都保存在這些文件中，查閱資料庫使用磁碟狀態可通過。

集合是結構上或概念上相似得文檔的容器，集合的名稱可以包含數字、字母或 . 符號，但必須以字母或數字開頭，完全。

限定集合名不能超過128個字元，實際上 . 符號在集合中很有用，能提供某種虛擬命名空間，這是一種組織上的原則，和其他集合是一視同仁的。在集合中可以使用。

其次是鍵值，在MongoDB裡面所有的字元串都是UTF-8類型。數字類型包括double、int、long。日期類型都是UTC格式，所以在MongoDB裡面看到的時間會比北京時間慢8小時。整個文檔大小會限制在16m以內，因為這樣可以防止創建難看的數據類型，且小文檔可以提升性能，批量插入文檔理想數字范圍是10~200，大小不能超過16MB。

（1）索引能顯著減少獲取文檔的所需工作量，具體的對比可以通過 .explain()方法進行對比

（2）解析查詢時MongoDB通過最優計劃選擇一個索引進行查詢，當沒有最適合索引時，會先不同的使用各個索引進行查詢，最終選出一個最優索引做查詢

（3）如果有一個a-b的復合索引，那麼僅針對a的索引是冗餘的

（4）復合索引里的鍵的順序是很重要的

（1）單鍵索引

（2）復合索引

（3）唯一性索引

（4）稀疏索引

如索引的欄位會出現null的值，或是大量文檔都不包含被索引的鍵。

如果數據集很大時，構建索引將會花費很長的時間，且會影響程序性能，可通過

當使用 mongorestore 時會重新構建索引。當曾經執行過大規模的刪除時，可使用

對索引進行壓縮，重建。

（1）查閱慢查詢日誌

（2）分析慢查詢

注意新版本的MongoDB 的explain方法是需要參數的，不然只顯示普通的信息。

本節同樣主要簡單呈現MongoDB副本集搭建的簡易性，與副本集的強壯性，監控容易性

提供主從復制能力，熱備能力，故障轉移能力

實際上MongoDB對副本集的操作跟mysql主從操作是差不多的，先看一下mysql的主從數據流動過程

而MongoDB主要依賴的日誌文件是oplog

寫操作先被記錄下來，添加到主節點的oplog里。與此同時，所有從結點復制oplog。首先，查看自己oplog里最後一條的時間戳；其次，查詢主節點oplog里所有大於此時間戳的條目;最後，把那些條目添加到自己的oplog里並應用到自己的庫里。從節點使用長輪詢立即應用來自主結點oplog的新條目。

當遇到以下情況，從節點會停止復制

local資料庫保存了所有副本集元素據和oplog日誌

可以使用以下命令查看復制情況

每個副本集成員每秒鍾ping一次其他所有成員，可以通過rs.status()看到節點上次的心跳檢測時間戳和 健康 狀況。

這個點沒必要過多描述，但是有一個特殊場景，如果從節點和仲裁節點都被殺了，只剩下主節點，他會把自己降級成為從節點。

如果主節點的數據還沒有寫到從庫，那麼數據不能算提交，當該主節點變成從節點時，便會觸發回滾，那些沒寫到從庫的數據將會被刪除，可以通過rollback子目錄中的BSON文件恢復回滾的內容。

（1）使用單節點鏈接

只能鏈接到主節點，如果鏈接到從節點的話，會被拒絕寫入操作，但是如果沒有使用安全模式，因為mongo的fire and forget 特性，會把拒絕寫入的異常給吃掉。

（2）使用副本集方式鏈接

能根據寫入的情況自動進行故障轉移，但是當副本集進行新的選舉時，還是會出現故障，如果不使用安全模式，依舊會出現寫不進去，但現實成功的情況。

分片是資料庫切分的一個概念實現，這里也是簡單總結為什麼要使用分片以及分片的原理，操作。

當數據量過大，索引和工作數據集佔用的內存就會越來越多，所以需要通過分片負載來解決這個問題

（1）分片組件

（2）分片的核心操作

分片一個集合：分片是根據一個屬性的范圍進行劃分的，MongoDB使用所謂的分片鍵讓每個文檔在這些范圍里找到自己的位置

塊：是位於一個分片中的一段連續的分片鍵范圍，可以理解為若干個塊組成分片，分片組成MongoDB的全部數據

（3）拆分與遷移

塊的拆分：初始化時只有一個塊，達到最大塊尺寸64MB或100000個文檔就會觸發塊的拆分。把原來的范圍一分為二，這樣就有了兩個塊，每個塊都有相同數量的文檔。

遷移：當分片中的數據大小不一時會產生遷移的動作，比如分片A的數據比較多，會將分片A裡面的一些塊轉移到分片B裡面去。分片集群通過在分片中移動塊來實現均衡，是由名為均衡器的軟體進程管理的，任務是確保數據在各個分片中保持均勻分布，當集群中擁有塊最多的分片與擁有塊最少分片的塊差大於8時，均衡器就會發起一次均衡處理。

啟動兩個副本集、三個配置伺服器、一個mongos進程

配置分片

（1）分片查詢類型

（2）索引

分片集合只允許在_id欄位和分片鍵上添加唯一性索引，其他地方不行，因為這需要在分片間進行通信，實施起來很復雜。

當創建分片時，會根據分片鍵創建一個索引。

（1）分片鍵是不可修改的、分片鍵的選擇非常重要

（2）低效的分片鍵

（3）理想的分片鍵

（1）部署拓撲

根據不同的數據中心劃分

這里寫圖片描述

（2）最低要求

（3）配置的注意事項

需要估計集群大小，可使用以下命令對現有集合進行分片處理

（4）備份分片集群

備份分片時需要停止均衡器

（1）部署架構

使用64位機器、32位機器會制約mongodb的內存，使其最大值為1.5GB

（2）cpu

mongodb 只有當索引和工作集都可放入內存時，才會遇到CPU瓶頸，CPU在mongodb使用中的作用是用來檢索數據，如果看到CPU使用飽和的情況，可以通過查詢慢查詢日誌，排查是不是查詢的問題導致的，如果是可以通過添加索引來解決問題

mongodb寫入數據時會使用到CPU，但是mongodb寫入時間一次只用到一個核，如果有頻繁的寫入行為，可以通過分片來解決這個問題

（3）內存

大內存是mongodb的保障，如果工作集大小超過內存，將會導致性能下降，因為這將會增加數據載入入內存的動作

（4）硬碟

mongodb默認每60s會與磁碟強制同步一次，稱為後台刷新，會產生I/O操作。在重啟時mongodb會將磁碟裡面的數據載入至內存，高速磁碟將會減少同步的時間

（5）文件系統

使用ext4 和 xfs 文件系統

禁用最後訪問時間

（6）文件描述符

linux 默認文件描述符是1024，需要大額度的提升這個額度

（7）時鍾

mongodb各個節點伺服器之間使用ntp伺服器

（1）綁定IP

啟動時使用 - -bind_ip 命令

（2）身份驗證

啟動時使用 - -auth 命令

（3）副本集身份認證

使用keyFile，注意keyFile文件的許可權必須是600，不然會啟動不起來

（1）拓撲結構

搭建副本集至少需要兩個節點，其中仲裁結點不需要有自己的伺服器

（2）Journaling日誌

寫數據時會先寫入日誌，而此時的數據也不是直接寫入硬碟，而是寫入內存

但是Journaling日誌會消耗內存，所以可以在主庫上面關閉，在從庫上面啟動

可以單獨為Journaling日誌使用一塊固態硬碟

在插入時，可以通過驅動確保Journaling插入後再反饋，但是會非常影響性能。

logpath 選項指定日誌存儲地址

-vvvvv 選項（v越多，輸出越詳細）

db.runCommand({logrotare:1}) 開啟滾動日誌

（1）serverStatus

這里寫圖片描述

（2）top

（3）db.currentOp()

動態展示mongodb活動數據

佔用當前mongodb監聽埠往上1000號的埠

（1）mongomp

把資料庫內容導出成BSON文件，而mongorestore能讀取並還原這些文件

（2）mongorestore

把導出的BSON文件還原到資料庫

（3）備份原始數據文件

可以這么做，但是，操作之前需要進行鎖庫處理 db.runCommand({fsync:1,lock:true})

db.$cmd.sys.unlock.findOne() 請求解鎖操作，但是資料庫不會立刻解鎖，需要使用db.currentOp()驗證。

（1）修復

mongd --repair 修復所有資料庫

db.runCommand({repairDatabase:1}) 修復單個資料庫

修復就是根據Jourling文件讀取和重寫所有數據文件並重建各個索引

（2）壓緊

壓緊，會重寫數據文件，並重建集合的全部索引，需要停機或者在從庫上面運行,如果需要在主庫上面運行，需要添加force參數 保證加寫鎖。

（1）監控磁碟狀態

（2）為提升性能檢查索引和查詢

總的來說，掃描盡可能少的文檔。

保證沒有冗餘的索引，冗餘的索引會佔用磁碟空間、消耗更多的內存，在每次寫入時還需做更多工作

（3）添加內存

dataSize 數據大小 和 indexSize 索引大小，如果兩者的和大於內存，那麼將會影響性能。

storageSize超過dataSize 數據大小 兩倍以上，就會因磁碟碎片而影響性能，需要壓縮。

『柒』 搭建MongoDB單節點副本集服務

mongo普通單節點不支持事務，需要使用副本集或者mongos才行，原因如下

參考官方文檔

使用docker只需要三步即可啟動一個副本集節點用於開發測試

『捌』 新手求教MongoDB副本集配置問題

網路MongoDB副本集群配置，有完整教程。
1：首先創建3台虛擬機作為配置環境 IP1：192.168.91.128 IP2：192.168.91.129 IP3：192.168.91。

『玖』 如何正確配置基於 oracle 資料庫的 wps v6.12 集群應用系統

本文描述了遠程消息傳遞和遠程支持集群環境的搭建配置過程。這個集群環境由三個集群組成，具體的拓撲結構是：
應用程序集群，不但為應用程序提供工作負載管理以及URL和EJB 請求故障轉移功能，而且還部署了BPC和HTM 容器，提供了對長業務流程和人工業務流程的應用程序的支持。
遠程消息集群，運行WPS默認提供的四個匯流排（SCA應用，SCA系統，BPC和CEI）提供獨立的高效的消息引擎。
遠程支持集群，部署通用事件體系結構和業務規則管理等其他應用程序，提供非同步的事件查詢。
這三個集群配置在兩台機器的不同的節點上，即三個集群的成員水平部署在兩台機器上。在一個集群中的兩個成員是該集群中完全相同的副本。消息傳遞引擎、業務支持和業務流程應用程序分別位於不同的集群上，所以可以根據實際業務負載和硬體環境，靈活調配所需的資源。這種模式，也稱為黃金拓撲，是 WPS 中最復雜的拓撲結構，是大多數企業集成應用用戶的首選，具有如下優點：

可靠性。將所有的應用、消息引擎和通用事件部署在三個集群上面，方便管理和使用。
可擴展性。因為系統中的消息引擎處於的關鍵地位，可能存在之後的訪問需求增長等擴展需要，單獨創建消息引擎集群可以很方便實行這一點。
對於系統運行時可能遇到的處理量非常大和可伸縮性等問題，通過將通用事件基礎架構（CEI）和應用程序分離，可以確保這兩個組件不會爭用相同的資源（內存和CPU）。此拓撲還能幫助創建集中的事件伺服器以處理來自多個源的事件。
所有的應用伺服器由 Deployment Manager 統一管理，降低了系統管理的復雜度。
安裝前的注意事項
在集群環境的安裝過程中，需要同步兩台主機的信息，確保它們之間能夠良好的通信。主要同步的信息包括兩台主機的系統時間、時區設置，並確保兩台機器的時間差在5分鍾之內，如果時間差超過5分鍾，聯合操作將失敗。
更新兩台主機的hosts 文件（默認目錄為/etc/hosts ），確保每台機器均包含對方的host name 和對應的IP 地址，以便主機間的相互訪問。
在使用向導安裝和配置概要時，請按照從上到下的順序輸入配置參數，對於WPS V6.12 ，輸入順序的改變有可能導致未知錯誤。
集群環境的搭建步驟
Informix 資料庫規劃
WPS的集群環境需要後台資料庫的支持。為了提高集群在實際運行中的效率，建議根據功能的不同，創建不同的資料庫。資料庫的詳細信息如下表所示：

資料庫名稱 說明
WPRCSDB 公共資料庫
EVENT 通用事件體系結構資料庫
CEIDB 通用事件體系結構消息傳遞引擎資料庫
SCASYSDB 服務組件系統消息傳遞引擎資料庫
SCAAPPDB 服務組件應用程序消息傳遞引擎資料庫
BPCDB 業務流程編排器資料庫
BPCME 業務流程編排器消息傳遞引擎資料庫
OBSVRDB 業務流程編排器事件收集器資料庫

注意：本文選擇英文語言的資料庫安裝。如果要安裝中文語言的資料庫，請參考本文的：在數據源定製屬性中添加資料庫語言。

安裝WPS的步驟
首先使用圖形化安裝向導在兩台主機上分別安裝WPS v6.1.2 產品，。在安裝產品和搭建集群過程中，步驟如下：
1.選擇「Typical installation」安裝類型。典型安裝也稱為完全安裝，提供了環境的初始化定義，包括通過概要管理工具創建特定了類型的概要文件。
圖2 選擇安裝類型

2.在選擇概要類型界面提供了四種可選擇的概要類型（圖3）。我們選擇「None」，即不創建任何類型的概要，以便在以後的步驟中手動創建概要。
使用Profile Management Tool（PMT） 創建Deployment Manager 概要

Deployment Manager（DM）是管理控制節點，它對集群環境下的所有節點提供了圖形化的管理功能。一個集群環境中一般只需要一個管理概要。下面我們將向您講述創建DM 概要的主要步驟：
1. 在<WPS_HOME>/bin/ProfileManagement/ 下執行命令pmt.sh ，彈出安裝界面。在各種類型的環境選項中選擇 WPS，進入下一步。
2. 在概要類型中提供了三種典型的概要類型，選擇 Deployment manager profile，搭建DM 概要。
3. 在創建方式界面中，默認選項為創建典型的概要文件，在此需要選擇 Advanced profile creation，以便我們在後續步驟中通過管理控制台手動進行集群配置，以滿足特定環境的需求。
4. 填寫要創建的Deployment manager profile的名稱和安裝目錄。
5. 填寫概要的Node Name和Cell name ，指定 Host Name。
6. 在管理安全選項中，如果選中 Enable administrative security 選項，請記住 WPS v 6.1.2
用戶名稱和密碼。這里建議取消 Enable administrative security 選項，不設置安全管理。在後續步驟中可以根據需要手動啟動安全管理選項，設定用戶名密碼。
7. 配置伺服器的埠。
8. 進行資料庫的配置。首先從 Choose a database proct 選擇 Informix Dynamic Server 作為公共資料庫類型，並選擇 Use an existing database。另外，需要指定 Database name，本例中使用先前創建的資料庫 WPRCSDB。不選擇「Deplay execution of database scripts for new or existing database」選項，因為概要文件的安裝過程中會自動創建資料庫 WPRCSDB 中的表。注意：如果創建的資料庫為中文字元集，則需要選擇 「Deplay execution of database scripts for new or existing database「選項，在概要創建完成後，手動執行創建資料庫表（請參考本節內容中的步驟 11）。

9. 在資料庫配置的第2步，需要對 Common DB 參數進行配置。如果是遠程資料庫，則在填寫 Database server host name時，要確保遠程資料庫的host name 已經添加到本地主機（參考本文的第三部分內容「安裝前的注意事項」）；也可以直接在該項填寫遠程資料庫的IP 地址。換句話說，在點擊下一步之前，請確認資料庫的參數信息，否則將在點擊下一步後，會收到不能連接資料庫的錯誤提示。
10. 完成以上步驟後，系統會顯示概要的創建信息。如果發現參數需要調整可以後退向導重新進行輸入。DM 創建成功後，可取消選擇 Launch the First steps console和Create another profile，點擊完成。至此，Deployment Manager 創建完成。如果創建DM 失敗，請查看 <WPS_HOME>/logs/manageprofile 目錄下的日誌文件進行分析。

11. 另外，如果需要手工創建Common DB(WPRCSDB) 相關的表，可執行DM 概要創建生成的資料庫腳本，默認目錄為：
<WPS_HOME>/profiles/Dmgr01/dbscripts/CommonDB/Informix/WPRCSDB 。
請將這些腳本復制到 Informix 資料庫所在機器，並設置如下環境變數：
INFORMIXSERVER=<IFX_INSTANCENAME>
INFORMIXDIR=<IFX_INSTALL_HOME>
之後執行如下命令：
dbaccess – createDatabase_CommonDB.sql
如果WPRCSDB已經創建，可以忽略。
dbaccess WPRCSDB createTable_AppScheler.sql
dbaccess WPRCSDB createTable_CommonDB.sql
dbaccess WPRCSDB createTable_customization.sql
dbaccess WPRCSDB createTable_lockmanager.sql
dbaccess WPRCSDB createTable_mediation.sql
dbaccess WPRCSDB createTable_Recovery.sql
dbaccess WPRCSDB createTable_RelationshipMetadataTable.sql
dbaccess WPRCSDB createTable_EsbLoggerMediation.sql
dbaccess WPRCSDB insertTable_CommonDB.sql
使用PMT 創建自定義概要
接下來，我們手動進行自定義概要的創建。這樣，能夠在創建概要過程中，根據客戶特定的使用需求和環境特點，選擇適合於自己的資料庫，並進行埠、用戶名、密碼等信息的設置。
在創建自定義概要（Custom profile）之前啟動 DeploymentManager（DM）概要，在目錄<WPS_HOME>/profiles/Dmgr01/bin 下，運行startManager.sh 命令。節點概要的創建與 DM 概要的創建類似，在目錄<WPS_HOME>/bin/ProfileManagment 下執行命令pmt.sh，隨即獲得安裝界面，主要步驟如下。
1．選擇 Create 即創建一個新的概要文件。
2．在環境選項中，選擇 WPS，進入下一步。
3．在創建概要的類型中，選擇 Custom Profile，創建一個自定義節點概要。
4．在安裝類型選項中，選擇 Advanced profile creation，以便在後續步驟中通過手動配置相關參數，定製特定的節點概要。

5．輸入節點所對應的DM 概要的主機名稱和埠，默認埠為8879。如果在創建DM時啟動了管理安全性，則需要輸入用戶名和密碼。Federate this node later 選項的選擇取決於是否要在創建節點的同時將其聯合到指定的DM 概要中。這里，我們不選擇該選項，節點會自動與 DM 概要聯合，需要注意的是，要確保 DM 概要此時為啟動狀態。
若選擇創建節點之後手動聯合到 DM 概要中，則需要在創建節點完成後使用<WPS_HOME>/Custom01/bin 目錄下的addNode.sh 命令進行節點與 DM的手動聯合，具體命令如下：
addNode.sh dmgr_hostname<–username username –password password>
6．輸入DM的信息後，進入埠設置頁面，可以自行修改埠號。

7．在資料庫選項中選擇 Informix Dynamic Server 作為資料庫類型，並為Informix JDBC driver 指定正確的路徑。該路徑指向節點所在的本地機器上 ifxjdbc.jar和ifxjdbcx.jar的存儲位置。
8．瀏覽匯總信息無誤後，點擊 Create 開始創建自定義概要。

9．創建成功後，重復以上步驟為另一台機器創建自定義概要。
命令行方式創建Deployment Manager 實例和託管節點實例
創建DM profile 和Custom profile時，除了使用pmt.sh 命令外，還可以選擇命令行方式，即執行<WPS_HOME> /bin/manageprofiles.sh 命令創建概要。創建Deployment manager 概要的命令和腳本如下：
./manageprofiles.sh –create -dbServerPort 8002
–templatePath <WPS_HOME>/profileTemplates/dmgr.wbiserver
–profileName Dmgr01
-dbDelayConfig true –dbCommonForME false
–dbType INFORMIX –dbHostName aix235.cn.ibm.com
–dbInstance IFXTest –hostName aix235.cn.ibm.com
–enableAdminSecurity false –dbName wprcsdb
–dbPassword informix –ndtopology false
-cellName aix235Cell01 –nodeName aix235CellManager01
–dbJDBCClasspath /opt/jdbc/lib –dbUserId Informix
–dbCreateNew false –profilePath <WPS_HOME>/profiles/Dmgr01
創建自定義節點的命令和腳本如下：
./manageprofiles.sh –create –dmgrHost 9.186.111.234
–profileName Custom01 –templatePath <WPS_HOME>/profileTemplates/managed.wbiserver
–dbType INFORMIX –ndtopology false
–cellName aix234Node01Cell –hostName aix234.cn.ibm.com
–nodeName aix234Node01 –dbJDBCClasspath /home/jdbc/lib
–dmgrPort 8879 –profilePath <WPS_HOME>/profiles/Custom01

『拾』 MongoDB復制集/副本集(Replica Set)搭建

mongo副本集/復制集是mongo高可用性特徵之一，是有自動故障恢復功能的主要集群。由一個Primary節點和一個或多個Secondary節點組成。

復制是在多台伺服器之間同步數據的過程，由一組Mongod實例（進程）組成，包含一個Primary節點和多個Secondary節點

Mongodb Driver（客戶端）的所有數據都寫入Primary，Secondary從Primary同步寫入的數據

通過上述方式來保持復制集內所有成員存儲相同的數據集，提供數據的高可用

Failover （故障轉移，故障切換，故障恢復）

Rendancy（數據冗餘）

避免單點，用於災難時恢復，報表處理，提升數據可用性

讀寫分離，分擔讀壓力

對用戶透明的系統維護升級

主節點記錄所有的變更到oplog日誌

輔助節點(Secondary)復制主節點的oplog日誌並且將這些日誌在輔助節點進行重放(做)

各個節點之間會定期發送心跳信息，一旦主節點宕機，則觸發選舉一個新的主節點，剩餘的輔助節點指向新的主

10s內各輔助節點無法感知主節點的存在，則開始觸發選舉

通常1分鍾內完成主輔助節點切換，10-30s內感知主節點故障，10-30s內完成選舉及切換

用戶恢復數據，防止數據丟失，實現災難恢復

人為誤操作導致數據刪除，程序Bug導致數據損壞等

首要復制節點，由選舉產生，提供讀寫服務的節點，產生oplog日誌

備用(輔助)復制節點，Secondary可以提供讀服務，增加Secondary節點可以提供復制集的讀服務能力

在故障時，備用節點可以根據設定的優先順序別提升為首要節點。提升了復制集的可用性

Arbiter節點只參與投票，不能被選為Primary，並且不從Primary同步數據

Arbiter本身不存儲數據，是非常輕量級的服務。

當復制集成員為偶數時，最好加入一個Arbiter節點，以提升復制集可用性

Mongodb版本3.0以上, 三台伺服器均為64位

三台伺服器    --------  Primary（Centos7)、 Secondary（Centos7)、 Secondary(Debian8)；架設IP分別為 192.168.1.1、1.2、 1.3

三台伺服器關閉防火牆    -------- systemctl  stop firewalld.service

三台伺服器修改mongo配置文件    --------  vi  /etc/mongod.conf 

        偵聽地址除了 localhost 外再加上伺服器IP； 設置復制集名字（RepliSetName）。

開啟mongod服務： mongod

三台伺服器mongo各自初始化： rs.initiate()

Primary上副本集配置：

rsconf(配置名稱，可隨意取)={_id:"副本集名",member:[{_id:0,host:"IP:port",priority:2},{_id:1,host:"IP:port",priority:1},{_id:2,host:"IP:port",priority:1}]}

在初始化：rs.initiate(變數名，如下面的config)

Secondary上配置：

rs.slaveOk()    #承認自己是Secondary

三台伺服器上互相添加副本集成員：

rs.add("IP:port")， 如在Primary上 rs.add("192.168.1.2:27017"), rs.add("192.168.1.3:27017")

查看狀態

rs.status()

3、rs(replication set) 常用命令：

初始化副本集  ----  rs.initiate()

mongo查看狀態 ---- rs.status()

初始化副本集配置

rsconf = {_id: "rs0",

members: [{

_id: 0,

host: ":27017"}]}

rs.initiate( rsconf )

驗證副本集配置  ----  rs.config()

增加副本集成員  ----  rs.add("Ip:port")

移除副本集成員  ----  rs.remove("IP:port")    #此步驟在Primary上操作

改變成員變數的優先順序

cfg = rs.conf()

cfg.members[0].priority = 3

cfg.members[1].priority = 1

cfg.members[2].priority = 2

rs.reconfig(cfg)

配置延遲副本集

cfg = rs.conf()

cfg.members[0].priority = 0

cfg.members[0].hidden = true

cfg.members[0].slaveDelay = 3600

rs.reconfig(cfg)

#  07/03/2017