前言
前段時間維護的一個事業群的其中一條業務線的開發找到運維，提出來了一個MongoDB的優化問題，那段時間MongoDB正在從op管理移交給db進行維護，整個部門都對MongoDB的運維經驗缺乏，MongoDB的優化更是一個未知的挑戰。當op找到我，核心系統的公共服務平臺用來進行短信服務的MongoDB集群想進行一次優化，我當仁不能讓的承擔了這項我都覺得可能搞不定的任務。
開發找到我提出了兩點兒問題，并尋求運維團隊解決這個問題，不過最終在我的理性的思考和他感性的思維碰撞下，最終我還是以勝利者的姿態勝出。我成功說服了他，并解答了他一些疑問，得到了滿意的答復后再也沒找我了。當然這里肯定不會就憑幾句話，任你理論再怎么豐富，態度如何曖昧，不拿點兒真實數據，做點兒什么，怎么能說服經驗豐富的開發認定的事兒。溝通了大半天，占據了我白天的工作時間，不過他提出來的問題還是很值得討論。
根據開發的邏輯，是想橫向擴充secondary節點，把其他要求不高的業務放到secondary節點上，減輕primary節點的壓力，達到部分讀寫分離，使得主要業務優先保障。我覺得這個出發點是好的，但并沒有就此作出回應，其一是他沒有認識到這個他認為的有延遲并不是數據庫集群的問題（這里不詳細講述排查的過程，下一篇文章會講些MongoDB的寫入與業務邏輯），其二是我們確實缺乏有效的資源硬件去進行擴充節點。
不同的業務場景應用不同的架構策略，擴充secondary節點有時候不能解決問題，尤其是那些實時性很高的業務，但有時候擴充secondary節點確實有效，比如硬件升級后需要做的服務遷移，需要在線擴充secondary節點來滿足業務需要的更高的硬件要求。
MongoDB的secondary節點的擴充，我總結起來有兩種方式：
1、rs.add()直接擴充
2、一致性備份后進行擴充（個人叫法）
1、rs.add("HOST_NAME:PORT")
具體的實現方式是登陸擴充節點的機器，編輯好配置文件，并建立相應的目錄和權限，啟動MongoDB實例就可以了。
需要注意的一點兒是這種擴充方式要保證同步源的數據量級，即保證在同步完數據前MongoDB的oplog不會被覆蓋，這點兒類似與MySQL的redo log日志，如果被覆蓋那么同步的數據出現不一致，導致同步失敗。
需要注意的另一點是同步數據的過程中，當集群數據達到一定量級時，同步數據的大小很大就會對網絡造成一定的壓力，可能對業務的核心交換機造成影響，因此需要用TC工具對同步流量做限速處理。這個限速需要考慮同步源可能不會是primary，也可能是同樣角色的secondary節點，令外限速同步勢必會增大同步時間，這個會增大oplog被覆蓋的概率，具體限速值還是要經過計算才能把握好。
2、一致性快照快速添加secondary節點（自我命名，歡迎各位交流）
a)primary節點上進行一致性快照備份
b)secondary節點上進行一致性快照恢復，僅僅對數據部分進行恢復，暫時不要對oplog進行恢復
c)初始化oplog.rs集合，并恢復oplog記錄
d)初始化local數據庫的其他兩個集合db.replset.election，db.system.replset
e)修改數據庫配置并重啟數據庫（這一步操作前實例不開啟認證模式、復制集的配置）,rs.add("HOST_NAME:PORT")將secondary添加進集群并觀察同步狀態、校驗數據的完整和一致性
實踐的詳細實踐過程如下（僅供參考交流，生產環境慎用）：
1、primary上進行一致性快照備份
#primary節點或者其他secondary節點備份數據
[root@172-16-3-190 mongodb]# /opt/app/mongodb/bin/mongodump -uroot -ppwd4mysql --authenticationDatabase=admin --port=27017 --oplog -o /tmp/dump_mongo/
2018-08-20T15:42:47.028+0800 writing admin.system.users to
2018-08-20T15:42:47.030+0800 done dumping admin.system.users (1 document)
2018-08-20T15:42:47.030+0800 writing admin.system.version to
2018-08-20T15:42:47.031+0800 done dumping admin.system.version (2 documents)
2018-08-20T15:42:47.032+0800 writing super_hero.user_address to
2018-08-20T15:42:47.032+0800 writing super_hero.user_info to
2018-08-20T15:42:47.033+0800 done dumping super_hero.user_address (1 document)
2018-08-20T15:42:47.033+0800 done dumping super_hero.user_info (1 document)
2018-08-20T15:42:47.034+0800 writing captured oplog to
2018-08-20T15:42:47.036+0800 dumped 1 oplog entry
#查看備份的文件
[root@172-16-3-190 mongodb]# ls -lh /tmp/dump_mongo/
total 12K
drwxr-xr-x 2 root root 4.0K Aug 20 15:42 admin
-rw-r--r-- 1 root root 110 Aug 20 15:42 oplog.bson
drwxr-xr-x 2 root root 4.0K Aug 20 15:42 super_hero
#傳遞備份到準備添加為secondary的節點上
[root@172-16-3-190 tmp]# scp -r -P22222 /tmp/dump_mongo/ liyingxiao@172.16.3.189:/tmp
2、secondary節點一致性快照恢復
#auth=true
#replSet = repl_mongo
#clusterAuthMode=keyFile
#keyFile=/opt/app/mongodb/keyfile/mongodb.key
##恢復數據
[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongorestore --oplogReplay --port=27017 /tmp/dump_mongo/
2018-08-20T15:56:32.161+0800 preparing collections to restore from
2018-08-20T15:56:32.193+0800 reading metadata for super_hero.user_info from /tmp/dump_mongo/super_hero/user_info.metadata.json
2018-08-20T15:56:32.194+0800 reading metadata for super_hero.user_address from /tmp/dump_mongo/super_hero/user_address.metadata.json
2018-08-20T15:56:32.222+0800 restoring super_hero.user_address from /tmp/dump_mongo/super_hero/user_address.bson
2018-08-20T15:56:32.300+0800 restoring super_hero.user_info from /tmp/dump_mongo/super_hero/user_info.bson
2018-08-20T15:56:32.867+0800 no indexes to restore
2018-08-20T15:56:32.867+0800 finished restoring super_hero.user_address (1 document)
2018-08-20T15:56:32.881+0800 no indexes to restore
2018-08-20T15:56:32.881+0800 finished restoring super_hero.user_info (1 document)
2018-08-20T15:56:32.881+0800 restoring users from /tmp/dump_mongo/admin/system.users.bson
2018-08-20T15:56:32.993+0800 replaying oplog
2018-08-20T15:56:32.997+0800 done
3、初始化oplog.rs集合，并恢復oplog記錄
創建oplog.rs集合并初始化大小
use local
db.createCollection("oplog.rs",{"capped":true,"size":100000000})
恢復一致性備份的oplog.rs集合的數據到secondary節點
[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongorestore -d local -c oplog.rs --port=27017 /tmp/dump_mongo/oplog.bson
2018-08-20T16:12:49.848+0800 checking for collection data in /tmp/dump_mongo/oplog.bson
2018-08-20T16:12:49.852+0800 restoring local.oplog.rs from /tmp/dump_mongo/oplog.bson
2018-08-20T16:12:49.925+0800 no indexes to restore
2018-08-20T16:12:49.925+0800 finished restoring local.oplog.rs (1 document)
2018-08-20T16:12:49.925+0800 done
4、初始化db.replset.election，db.system.replset集合，其中replset.election需要查詢主節點數據并將這些數據存儲到secondary節點，或者兩個結合自行save到secondary節點。另集合system.replset加入復制集后可自動識別primary節點內容（這里我采取自行同步數據）
#primary節點
repl_mongo:PRIMARY> db.replset.election.find()
{ "_id" : ObjectId("5b7a6ee5de7a24b82a686139"), "term" : NumberLong(1), "candidateIndex" : NumberLong(0) }
#secondary節點
db.replset.election.save({ "_id" : ObjectId("5b7a6ee5de7a24b82a686139"), "term" : NumberLong(1), "candidateIndex" : NumberLong(0) })
5、修改數據庫配置并重啟，添加secondary節點到復制集群中
#auth=true
#replSet = repl_mongo
#clusterAuthMode=keyFile
#keyFile=/opt/app/mongodb/keyfile/mongodb.key
[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongod --shutdown -f /opt/app/mongodb/mongo.conf
killing process with pid: 5331
[root@172-16-3-189 we_ops_admin]# vim /opt/app/mongodb/mongo.conf #注釋去掉并重啟
[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongod -f /opt/app/mongodb/mongo.conf
about to fork child process, waiting until server is ready for connections.
forked process: 5722
child process started successfully, parent exiting
#添加secondary節點
repl_mongo:PRIMARY> rs.add({"_id":1,"host":"172.16.3.189:27017"})
{
"ok" : 1,
"operationTime" : Timestamp(1534752953, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1534752953, 1),
"signature" : {
"hash" : BinData(0,"Tt9nzhoVYdUtGFZnc1Kg1exl0Hc="),
"keyId" : NumberLong("6591702943026642945")
}
}
}
6、登錄添加的secondary節點，驗證復制集狀態，數據完整和一致性。
[root@172-16-3-189 we_ops_admin]# /opt/app/mongodb/bin/mongo -uroot -ppwd4mysql --authenticationDatabase=admin --port=27017
重點介紹第二種省時省心但費力費操作的添加secondary節點的方法，實踐過程中數據庫實例前期去掉認證和復制集參數，是方便我們下面的一些需要用戶權限的操作，避免建立管理員賬號，后續加入集群后自行同步了primary節點的賬號。重啟后登錄secondary節點驗證服務的可用性和數據一致性時，使用集群的管理賬號進入，否則會報認證的錯誤。
總結如上兩種擴充方式，對于方式1的擴充簡單省事，需要保證oplog不被覆蓋和評估同步流量的影響問題，是我們通常進行橫向復制集添加secondary節點的方法。對于第二種方式，操作繁瑣但不用擔心oplog被覆蓋，且操作期間不會過多擔憂網絡流量的問題，僅僅考慮網絡傳輸的流量影響。第一種方式操作時間周期長，不可控的影響范圍大費時費精力，第二種方式操作時間短，操作的步驟多，容易出現其他問題。
MongoDB secondary節點出現recovering狀態
MongoDB做了replica sets之后,secondary節點出現recovering狀態
在一次mongo集群掛掉后，重啟，發現有一臺服務器的mongo節點一直處于recovering狀態，不能變為secondary或者primary。
查詢官方文檔后，找到解決方案，在此記錄。
出現原因
備份節點的工作原理過程可以大致描述為，備份節點定期輪詢主節點上的數據操作，然后對自己的數據副本進行這些操作，從而保證跟主節點的數據同步。
至于主節點上的所有數據庫狀態改變的操作，都會存放在一張特定的系統表中。備份節點則是根據這些數據進行自己的數據更新。
上面提到的數據庫狀態改變的操作，稱為oplog（operation log，主節點操作記錄）。oplog存儲在local數據庫的"oplog.rs"表中。副本集中備份節點異步的從主節點同步oplog，然后重新執行它記錄的操作，以此達到了數據同步的作用。
關于oplog有幾個注意的地方：
- oplog只記錄改變數據庫狀態的操作
- 存儲在oplog中的操作并不是和主節點執行的操作完全一樣，例如"$inc"操作就會轉化為"$set"操作
- oplog存儲在固定集合中(capped collection)，當oplog的數量超過oplogSize，新的操作就會覆蓋舊的操作
數據同步
在副本集中，有兩種數據同步方式：
- initial sync（初始化）：這個過程發生在當副本集中創建一個新的數據庫或其中某個節點剛從宕機中恢復，或者向副本集中添加新的成員的時候，默認的，副本集中的節點會從離它最近的節點復制oplog來同步數據，這個最近的節點可以是primary也可以是擁有最新oplog副本的secondary節點。
- 該操作一般會重新初始化備份節點，開銷較大
- replication（復制）：在初始化后這個操作會一直持續的進行著,以保持各個secondary節點之間的數據同步。
initial sync
當遇到上面例子中無法同步的問題時，只能使用以下兩種方式進行initial sync了
- 第一種方式就是停止該節點，然后刪除目錄中的文件，重新啟動該節點。這樣，這個節點就會執行initial sync
注意：通過這種方式，sync的時間是根據數據量大小的，如果數據量過大，sync時間就會很長
同時會有很多網絡傳輸，可能會影響其他節點的工作
- 第二種方式，停止該節點，然后刪除目錄中的文件，找一個比較新的節點，然后把該節點目錄中的文件拷貝到要sync的節點目錄中
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。
您可能感興趣的文章:- 關于mongoose連接mongodb重復訪問報錯的解決辦法
- NodeJS連接MongoDB數據庫時報錯的快速解決方法
- perl操作MongoDB報錯undefined symbol: HeUTF8解決方法
- centos7防火墻導致java程序訪問mongodb3.0.1時報錯的問題分析
- mongodb replica set 添加刪除節點的2種方法
- Mongodb增加、移除Arbiter節點實例
- mongodb添加arbiter節點的方法示例
- MongoDB添加仲裁節點報錯：replica set IDs do not match的解決方法
