WiredTiger 是一個開源的、高性能帅刊、可伸縮的 MongoDB 數(shù)據(jù)存儲引擎法挨。

SSPL協(xié)議是只對使用云廠商提供的MongoDB存儲服務有要求，但是對于我們自己在云廠商主機上部署自己的MongoDB數(shù)據(jù)庫是沒有任何限制的逛薇，是吧？

按SSPL協(xié)議疏虫，最多也只能到MongoDB4.0版本金刁。

這可能也是阿里云、百度云等云廠商上提供的MongoDB數(shù)據(jù)庫版本最多也是到MongoDB4.0的原因议薪？

正解。這個只影響云廠商的MongoDB托管服務的部門媳友。你自己在云上部署是不受SSPL限制的斯议。

mongDB社區(qū)版使用的是 SSPL 協(xié)議，?和標準開源AGPL協(xié)議最大的差別就是 Mongo的不允許公有云廠商在云上賣MongoDB云服務醇锚。

阿里云已經獲得商業(yè)授權所以他們接下來可以繼續(xù)提供更新版本哼御。其他云暫時就只能到4.0，正如你已經觀察到的焊唬。

?mongodb適合做數(shù)據(jù)倉庫嗎恋昼？

如果是傳統(tǒng)用來做星形schema或者雪花schema，不是太合適赶促。

如果是用來做現(xiàn)代數(shù)倉液肌，類似于大數(shù)據(jù)那樣做大寬表，mongodb可以作為一個選擇鸥滨。

我在我自己的類似數(shù)倉的平臺產品里就用了mongodb嗦哆。?

有一些比較不錯的亮點是：橫向擴展能力，多結構化數(shù)據(jù)支持婿滓，檢索能力老速，元數(shù)據(jù)管理等

最近在java項目中嘗試將日志輸出到mongodb，發(fā)現(xiàn)效果挺不錯凸主，解決了日志集中存儲橘券，分析排查問題方便了很多。

我想問的是 為什么現(xiàn)在微服務架構中流行用elk方案處理日志卿吐，mongodb不是更方便 更簡單嗎旁舰？ 由于我沒做過對比測試 不知mongodb存日志會不會有什么不足之處？

ELK 除了存儲日志之外但两，有一些另外的插件比如說Logstash 可以用來用工具方式收集一些日志文件鬓梅，比如說Kibana可以用來做一些日志分析和可視化的工作。另外ELK在日志全文搜索方面也略勝一籌谨湘。

你的場景是從Java 里寫日志就沒有太大區(qū)別了绽快，mongo 和ES都可以很好的解決芥丧。當然，像我們公司一樣因為已經用MongoDB 作為數(shù)據(jù)庫坊罢，那我們就不需要額外再去用另一個分布式系統(tǒng)了续担。架構可以簡單很多，這個可能是mongo能夠作為一個通用數(shù)據(jù)庫而不只是某些日志或搜索功能的優(yōu)勢了活孩。

關于mongodb在loT領域的應用物遇，比如怎樣實現(xiàn)時序數(shù)據(jù)庫的功能？

MongoDB不是一個專門的IoT憾儒，但是可能在70%-80%的IoT場景下它可以是個不錯的選擇询兴。只有你在考慮有幾十億幾百億的量級，并且要做海量數(shù)據(jù)分析的時候起趾，Mongo的行級存儲特性會使得它不是最優(yōu)的選擇诗舰。這個時候要考慮專門的IoT數(shù)據(jù)庫了。

Mongo的優(yōu)勢：

1）足夠好的擴展能力來支撐大部分的IoT時序數(shù)據(jù)的存儲训裆，特別是使用了分桶設計以后（第2章我會講）?

2）靈活的JSON模型眶根，特別適合各種傳感器的不規(guī)則數(shù)據(jù)結構。

國內的某一大廠物聯(lián)網(wǎng)方案就是基于mongo的边琉。西門子的工業(yè)物聯(lián)網(wǎng)Mindsphere也是用mongo属百。非常多的使用者。

http://mongoing.com上的MongoDB中文文檔是3.4的变姨，現(xiàn)在MongoDB的版本已經到4.2了族扰，3.4的文檔跟4.2文檔的差別大嗎？mongoing.com后面會翻譯4.0版本的文檔嗎钳恕？現(xiàn)在看3.4的文檔翻譯是 2017年的了别伏。

mongodb的官方文檔工具升級后就不支持非英語語言的合并，造成翻譯的文檔難以更新忧额。

這個問題我們已經反應給官方厘肮，我們還在看有無機會等他們更新工具后重新啟動新版翻譯。

看到很多書或者其他資料中說MongoDB是BSON數(shù)據(jù)模型睦番，能解釋一下BSON嗎类茂？

BSON 是MongoDB用來在落盤存儲時候或者網(wǎng)絡傳輸時候的底層物理數(shù)據(jù)模型。

如果你是存儲引擎開發(fā)者或者mongodb驅動程序開發(fā)者托嚣，你需要從這個層面去了解巩检。如果你是絕大部分的應用開發(fā)者或者數(shù)據(jù)庫使用者，你只需要關心JSON示启。

BSON = Binary JSON兢哭， 是基于JSON基礎上加了一些類型及元數(shù)據(jù)描述的格式。

MongoDB 的特性是無Schema 設計夫嗓，但在使用過程中通過 Java (Spring Boot)操作時需要先定義對象結構迟螺，加上相應的注解冲秽，與 MongoDB 的 Feild 對應，這樣其實 沒有辦法利用 MongoDB 的這一特性了矩父，有什么辦法嗎锉桑？

MongoDB是動態(tài)Schema，不是無schema窍株。

你定了一個schema以后民轴，以后新增字段（在springboot）的時候，直接改就可以了球订，不需要去數(shù)據(jù)庫調整后裸。這就是它的優(yōu)越性。

mongoDB這門課需要什么樣的基礎冒滩？需要懂開發(fā)語言么轻抱？

懂一些Javascript的話會比較有幫助一些。如果是只做管理的DBA旦部，你可能也需要一些Javascript來維護下數(shù)據(jù)。

當然较店，我不覺得用JS來做些腳本就一定要是像開發(fā)者那樣熟練士八，所以說不是100%需要懂開發(fā)語言。

您在課程中提到“介紹 MongoDB 的基本操作”這個任務梁呈，是留給“參考書”去做的婚度。那么您能否推薦一些，這種用來給初學者入門的“參考書”官卡，或者是網(wǎng)絡上的學習資源呢蝗茁？

MongoDB: The Definitive Guide

有中文譯本：MongoDB權威指南

Mongodb 操作系統(tǒng)優(yōu)化這塊推薦的參數(shù)？

可以參考一下這里：

https://docs.mongodb.com/manual/administration/production-notes

MongoDB是一個基于json的數(shù)據(jù)庫寻咒，文檔模型靈活哮翘，很好橫向擴展能力

2.x版本加入聚合的操作

3.x版本引入wiredtiger引擎

4.x版本引入事務acid的支持

為什么副本集說是5個9（99.999%）的高可用？

MongoDB復制集在從節(jié)點故障時候是不會影響到可用性毛秘。

在主節(jié)點故障饭寺，進行選舉的時候需要數(shù)秒到十幾秒，這期間會影響寫入叫挟。

一年有365天x86640秒 ~= 3000多萬秒艰匙。假設你每個月發(fā)生一次主節(jié)點故障或者其他問題導致選舉，每次影響15秒抹恳，那么可用率就是：就是（3000w-12x15） / 3000w ~= 99.9994%

MongoDB這種復制集模式员凝，在不同的數(shù)據(jù)中心，這中間的網(wǎng)絡延遲比較嚴重吧奋献，不會影響做復制集的效果嗎健霹？

數(shù)據(jù)規(guī)模達到多大級別需要使用分片機制旺上？，我們現(xiàn)在數(shù)據(jù)有200多G骤公，是不是復制集已經足以應對了抚官？

在多中心部署的時候要考慮網(wǎng)絡延遲，所以一般多活中心只是建議能夠接受一定數(shù)據(jù)延遲的情況下才建議阶捆。

分片有3個觸發(fā)條件：數(shù)據(jù)量凌节，并發(fā)量，以及熱數(shù)據(jù)大腥魇浴（內存需求）倍奢。理論上，任意一個都會觸發(fā)分片需求垒棋。如果只看數(shù)據(jù)量卒煞，單分片一般可以到1-2TB。

mongoDB和MySQL比寫入性能方面優(yōu)勢大嗎?

按照我個人經驗是有明顯的優(yōu)勢的叼架。有好幾家大廠的兄弟畔裕，包括百度，網(wǎng)易乖订，字節(jié)都有分享類似的經驗扮饶。?

稍微網(wǎng)絡搜一下，都有十倍或者更多的數(shù)字乍构。原因：

1）MongoDB默認的事務級別比MySQL低

2）MongoDB支持的batch 寫入模式可以大幅度提升寫入速度

3）MongoDB默認寫到內存就返回甜无，不等落盤

mongoDB是不是完爆MySQL呢？什么情況下該選用mysql而不是MongoDB呢哥遮？

實際情況是岂丘，很多同學在學校里學習的只是SQL。

很多開發(fā)團隊眠饮，特別是有項目壓力的奥帘，沒有時間讓團隊來學習，就會選擇大家比較熟悉的方式仪召。

如果有額外的時間的話翩概，我的幾個創(chuàng)業(yè)公司的朋友都說，想從MySQL 切換到MongoDB返咱。

為什么MySQL不用一張表多個字段呢钥庇，而是拆分成幾個表？

MySQL一張表沒法做到一對多的關系咖摹，只能拆分表來做评姨。

當然，MySQL現(xiàn)在也支持json了，但是那個是非主流用法吐句。對JSON的支持也是相對較弱胁后，所以使用人并不多。

MongoDB 支持multi-master嗦枢，所有節(jié)點可以同時讀寫數(shù)據(jù)庫嗎攀芯？

?在一個復制集群里沒有multi-master，但是一個分片集群可以有多個master (primary), 每個分片一個primary這種方式文虏。

mongoDB性能優(yōu)勢大不大呢侣诺？

如果不說單節(jié)點性能比較，MongoDB最少是分布式架構氧秘，可以通過橫向擴容來克服性能瓶頸年鸳。

這個和同樣是用來作為應用程序數(shù)據(jù)庫的RDBMS來比還是有很明顯的優(yōu)勢的。

Grafana不支持mongodb作為數(shù)據(jù)源丸相，也沒有相關插件，有什么方案灭忠，使用grafana顯示mongodb的一些數(shù)據(jù)嗎?

https://grafana.com/grafana/dashboards/8339

mongoDB有什么推薦的客戶端軟件嗎膳算？

MongoDB Compass（官方）

Studio3T

NoSQL Booster

navicat

mogodb安裝在linuc或windows上，運行差別很大嗎弛作？官方推薦是部署在什么系統(tǒng)上(難道大部分生產環(huán)境是部署在centos上)畦幢？

MongoDB生產環(huán)境絕大部分是Linux 系統(tǒng)。RedHat, CentOS, Ubuntu 等都有缆蝉。

Windows 開發(fā)環(huán)境多一點，也有少數(shù)線上使用瘦真。但是確實不是主流刊头。

差別：Linux版本上面用的最多，踩得坑也最多诸尽，相對更加穩(wěn)定原杂。

mongodb在生產環(huán)境建議使用docker部署嗎？用docker部署副本集如何處理您机？

docker 在生產環(huán)境中不建議穿肄。

在開發(fā)測試環(huán)境中okay，需要注意的一點是要用服務名或者配置的域名進行復制集的配置际看，否則可能會因為docker 內部ip無法互相通信而啟動不了集群咸产。

如果在docker容器中布署mongodb，一般容器內存與heap內存的比例大概是個什么比例仲闽？

?MongoDB 默認會使用60%的系統(tǒng)內存脑溢，一般至少也要用到1GB緩存，所以容器至少要給個2GB赖欣。

如果想對mongodb脫敏屑彻，非結構型的數(shù)據(jù)結構有什么好的解決方案推薦嗎验庙？

可以采用一些ETL工具，如Kettle, Talend, Tapdata等社牲。這些工具都對mongodb有一定程度的支持粪薛。

numa架構下現(xiàn)在安裝mongodb還需要配置interleave=all，進行交叉內存分配么搏恤？

這個還是建議的违寿。

看3.6的官方文檔，刪除是用deleteOne, deleteMany挑社，這跟remove有什么區(qū)分嗎?

remove是mongo shell下的命令陨界。deleteOne deleteMany是程序語言下的API。做的是類似的事情痛阻。

文件分布式的文件存儲也會選用MongoDB么菌瘪？除了MongoDB還有其他的解決方案嗎？

可以嘗試 minio

請問分片集群的chunk分裂閾值有哪些阱当？

shard key與chunk的分裂閾值是什么關系俏扩？

如何避免按shard key做chunk分裂時出現(xiàn)超出chunkSize的chunk塊？

這個閾值應該是在80%（64MB * 80%）的時候弊添，就會把塊一分為二录淡。

mongodb刪除了數(shù)據(jù)油坝、表嫉戚、數(shù)據(jù)庫是沒法恢復的么，有沒有類似mysql有個日志記錄的機制去回滾的澈圈？

?mongodb有類似的oplog彬檀。但是那個要求你對全量的oplog都要保存，才能夠從oplog里完全恢復被誤刪的表瞬女。

在外分布式環(huán)境中窍帝，mongo如何做開機自啟？

將服務注冊成系統(tǒng)服務：

CentOS6.x? 寫啟動腳本

CentOS7.x? 寫service文件

如果你是說希望有那種中央化的管控诽偷，那你可以使用OpsManager坤学，可以通過GUI對全部節(jié)點進行起停控制报慕，并且是會在服務器宕機時候自動重啟服務深浮。

使用mongodump的時候會給collection加lock嗎?

不會加lock。所以mongodump出來的不是一個一致的backup眠冈。通陈院牛可以加上 --oplog參數(shù)來獲取一個某個時間點的快照類的備份。

對于mongo副本集，如果有多個庫玄柠，由于單集群達到瓶頸了突梦，我想把一個庫遷移出去，有什么方法嗎羽利，能達到像mysql主從實現(xiàn)嗎宫患？并且切換到新集群控制在切換ip的時間嗎？

如果可以停服務这弧，可以用 mongodump -d xxx 方式如果不能停服娃闲，需要用一些工具：如果在阿里云，可以考慮mongoshake 工具MongoDB官方有mongomirror工具匾浪，我們Tapdata也有一個工具皇帮，有免費3個月的使用期，如果只是一次性遷移夠用了蛋辈。

我們系統(tǒng)一開始使用es, 但是我們的一個index包含2000多個field,經常會出現(xiàn)寫性能問題属拾，請問mongoDB對于寫入的文檔的字段，以及字段嵌套的深度由限制嗎冷溶？

那個沒有限制渐白。限制就是最大不能超過16MB。ES的長處是查詢/搜索逞频，寫入從來不是它優(yōu)勢纯衍。

MongoDB比較平衡點，增刪改查都還不錯苗胀。

使用mongodump去備份db襟诸，備份過程中會阻塞insert寫入嗎？

是不是如果不想要一致性備份集基协，就不上鎖歌亲，如果想要一致性的備份集，加--oplog參數(shù)堡掏，也不阻塞insert寫入？

備份不阻塞刨疼，除非你用fsyncLock（）泉唁。

不上鎖的話，就用 --oplog

mongodb的動態(tài)特性有缺點嘛揩慕？

有一些值得注意的地方亭畜。

schema 管理會復雜， 你不能一下確定這個集合到底是什么結構迎卤。

解決方案是使用Schema Validation 或者 JSON Schema來定義這個集合的嚴格結構拴鸵。?

JSON Schema類似于關系數(shù)據(jù)庫的schema，但是不同的是如果你需要修改這個schema的話可以隨時更改，理論上也不需要對已有數(shù)據(jù)做更新或者遷移劲藐。

我以前用的MySQL八堡，如果一個服務器上有多個數(shù)據(jù)庫，想遷移數(shù)據(jù)庫的時候直接考走對應的數(shù)據(jù)庫文件就好聘芜。如果是mongodb兄渺，發(fā)現(xiàn)沒有對應的文件，請問除了把數(shù)據(jù)導出還有別的辦法嗎汰现？

?mongodb 不能這么玩挂谍，只能用mongodump 或者 mongoexport，或者用遷移工具瞎饲。

比如在MySQL批量插入口叙，一次3000條左右比較合適，性能也不錯嗅战，如果是mongodb,一次插多少條比較高效妄田？

這個沒有絕對值，通常和文檔大小有關仗哨。如果在1KB以內的話形庭，我會推薦用1000左右的batch size

想刪除多行數(shù)據(jù)，得對多行數(shù)據(jù)進行備份厌漂，有什么工具可以生成反向語句insert進行備份嗎?

換一個思路萨醒。

使用MongoDB Ops Manager可以實現(xiàn)任意時間點恢復 - 比如你3：00執(zhí)行刪除動作，4：00發(fā)現(xiàn)有問題想回滾苇倡，那么可以使用ops manager 把數(shù)據(jù)庫回到3：00的時候富纸。

類似的事情可以用命令行方式做，但是就不是小項目了旨椒。反向生成insert的沒有見過晓褪，但是自己實現(xiàn)應該很簡單。

mongodb $in子句有長度限制嗎综慎？另外mongodb的 findMany返回的游標涣仿，會不會有內存溢出的問題呢？

理論上沒有示惊，只有bson 大小限制（16MB）好港。但實際上我用到1000的時候查詢就很慢了。

MongoDB官方好像是建議1主1從1arbiter米罚。如果是1主2從钧汹，主節(jié)點掛掉后，兩個從節(jié)點都投票給自己录择，這樣僵持审丘，不是會沒法產生新的master嗎？

“MongoDB官方好像是建議1主1從1arbiter” 請?zhí)峁┫鄳奈恼隆?/p>

主節(jié)點掛了以后焕参，兩個從節(jié)點的投票算法會防止你說的現(xiàn)象發(fā)生歹袁。

具體來說，如果兩個從節(jié)點條件完全一樣，那么第一個主張的節(jié)點就獲勝。如果兩個從節(jié)點同時主張自己，那么兩個人同時放棄精偿，并用一個隨機值等待一小段時間（數(shù)秒），然后重試赋兵。所以總有一個節(jié)點會在另一個之前選為主節(jié)點笔咽。

通常怎樣提高寫性能？

?升級存儲是最直接的方案霹期，如PCIE + SSD

- 注意索引的數(shù)量：索引越多寫入越慢

- 分片： 增加寫的節(jié)點來提供并發(fā)

如果是奇數(shù)節(jié)點叶组，那么主節(jié)點掛掉，不就變成偶數(shù)節(jié)點了历造？

總數(shù)是看最初的配置甩十，如你部署并配置了3個，雖然壞了一個吭产，但是你的拓撲還是3節(jié)點侣监， 按3節(jié)點的規(guī)則，剩下2個存活就可以正常工作臣淤。

1.建立3個獨立的單機庫橄霉，然后導入同一份數(shù)據(jù)，然后將3個節(jié)點設置為復制集模式邑蒋，那么被設置為從節(jié)點的數(shù)據(jù)庫里面的數(shù)據(jù)會被清空姓蜂，然后再從主節(jié)點再同步回來嗎？

2.如果3個節(jié)點通過公網(wǎng)ip地址互連医吊，那么這中間的數(shù)據(jù)通信需要做安全防護嗎钱慢？也就是這個時候節(jié)點間的通信數(shù)據(jù)被竊取，是否有泄露數(shù)據(jù)的風險卿堂？

1）是的會重新同步束莫。節(jié)點之間判斷是否需要同步是根據(jù)local庫里的元數(shù)據(jù)決定的。里面記錄了節(jié)點同步的狀態(tài)信息草描，并不是看你實際存儲的數(shù)據(jù)览绿。

2）建議用SSL/TLS 加密鏈路就可以有效防止數(shù)據(jù)被竊取。

https://docs.mongodb.com/manual/tutorial/configure-ssl/index.html

太多的slave 數(shù)據(jù)節(jié)點陶珠，都從主節(jié)點拉oplog 是否反而增加了主節(jié)點的壓力挟裂？反而讓主節(jié)點性能變差了享钞？

寫主 讀取從的這種配置是否還被推薦揍诽？什么場景適合這種诀蓉？

太多從節(jié)點會增加主節(jié)點的壓力，大概是每增加一個節(jié)點會有10%左右的性能影響暑脆。

主從讀寫分離還是比較常見的渠啤。所有讀操作對數(shù)據(jù)時效（如報表型，或者歷史數(shù)據(jù)）不高的都可以用從節(jié)點添吗。

增加副本集節(jié)點沥曹，只能提高并發(fā)訪問能力，單個查詢并不會變快碟联。

那么有辦法通過水平擴展的方式提高單個查詢的性能嗎妓美？

?通過水平擴展可以提高整體的吞吐量，但是單個（比如說鲤孵，查詢 id=1234 這條記錄）查詢是不會得到改善的壶栋。因為這個查詢就是會在一個節(jié)點上發(fā)生。

提高單個查詢性能就是把數(shù)據(jù)放在內存里普监，加上合適的索引可以來提升性能（降低讀取延遲）

選舉是發(fā)生在主節(jié)點故障時贵试，那么它也會參與投票么？

主節(jié)點故障如果是進程crash或者server crash凯正，那么它當然無法進行選舉毙玻。

如果故障是因為節(jié)點之間網(wǎng)絡不通，那失聯(lián)的主節(jié)點會自動降級為從節(jié)點廊散。

如果是短暫故障馬上回復后桑滩，主節(jié)點（這個時候已經是從節(jié)點了）會重新加入選舉，但是有個30秒的等待期奸汇。

復制集主從讀寫分離看起來很美好施符，但是如果對主從同步延時要求高，使用就很受限擂找。

比如某些業(yè)務會寫操作多，實時要求高的讀場景多贯涎，這樣主節(jié)點壓力就很大听哭，而從節(jié)點可以分擔的業(yè)務場景非常有限。

老師如何看待復制集架構在這種業(yè)務場景中的應用和優(yōu)化呢塘雳？

對陆盘。

讀寫分離的讀一般指的是對時效性要求不高的讀場景。

如果要求高一般都建議讀主節(jié)點败明。如果主節(jié)點性能扛不住隘马，這個時候就要采用分片集群來分擔壓力(讀和寫)。

我們想使用此方式來提高mongodb的查詢性能妻顶， 復制集采用一主兩從酸员，主節(jié)點使用memeory蜒车，從節(jié)點wiredtiger。 這樣是否能夠提供查詢效率幔嗦？

這樣做是OKAY的酿愧，當然要注意InMemory Engine是商業(yè)版產品需要付費。

之前有人用RAMDISK方式來模擬InMemory邀泉，但是由于代碼還是WT嬉挡，所以和真正的InMemory Engine還是有些差別。

復制集汇恤，有沒有集群庞钢，就是分布式存儲?

?復制集也是集群，3個節(jié)點以上的高可用集群因谎。

數(shù)據(jù)不做分布式存儲焊夸，只是主從熱備。

復制集能基于數(shù)據(jù)庫粒度嗎??

復制集只能同步所有數(shù)據(jù)庫嗎蓝角，能只同步選擇的數(shù)據(jù)庫嗎阱穗？

公司項目數(shù)據(jù)庫服務實例有多個數(shù)據(jù)庫,但是只想遷移部分數(shù)據(jù)庫. dump oplog選項也不支持數(shù)據(jù)庫粒度, 但是阿里云DTS和tapData又能基于oplog做數(shù)據(jù)庫粒度的毫秒級同步增量遷移,怎么做到的呢?

這個功能提了幾年了，但是還沒支持使鹅。

復制集的設計原理是基于3個節(jié)點是完全等同的基礎上（因為會主從切換）揪阶。

當然，對于某些指定的非主節(jié)點（第4個以上患朱，priority為0)鲁僚， 技術上實現(xiàn)庫級/選擇性同步是可以的的，只不過這個優(yōu)先級不高裁厅，沒有在mongo產品路線圖里實現(xiàn)而已冰沙。

1主2從的復制集節(jié)點，當主掛掉了执虹，怎么從2個從節(jié)點中選擇新的主節(jié)點呢拓挥？

主掛掉了，但是節(jié)點的架構沒有變袋励，還是3個節(jié)點（2個好的侥啤，1個壞的）。符合大多數(shù)原則茬故，可以選舉主節(jié)點盖灸。

1.主從這種配置實現(xiàn)了高可用和高并發(fā)，一主二從的配置其實就是一份數(shù)據(jù)最終落到了三臺機器磺芭，如果數(shù)據(jù)太多赁炎，導致磁盤不夠用，增加從節(jié)點是沒有用的對吧钾腺？是不是只能增加磁盤容量才可以徙垫？

2.對于mongo琅攘，究竟多大的數(shù)據(jù)量和并發(fā)量適合使用mongo，這個有什么評估標準嗎松邪？

1. 你的理解是正確的。需要分片或者增加容量哨查。

2. 如果不是為別的考量逗抑，只是數(shù)據(jù)量，通常我見的比較多的是億級以上的數(shù)據(jù)量寒亥，可以考慮mongodb邮府。

主從復制是否會產生延遲，如果有延遲溉奕，那么常見有哪些因素會導致延遲褂傀，該如何避免或者降低延遲?

主從復制會有延遲。常見因素：

1） 網(wǎng)絡抖動 （沒辦法）

2）網(wǎng)絡擁擠 （評估數(shù)據(jù)增量需求加勤，給予足夠的帶寬）

3）節(jié)點之間延遲太長

4）主節(jié)點壓力過大 （注意監(jiān)控仙辟，壓力過大要擴容）

5）從節(jié)點配置不均衡，低于主節(jié)點配置（盡量均衡）

副本集提高讀性能鳄梅，是指提高并發(fā)訪問的性能叠国，還是指單個查詢會變快？或者二者兼有之戴尸？

通過增加節(jié)點粟焊，并且每個節(jié)點同時提供服務來提高并發(fā)訪問能力。

單個查詢的性能不受影響（不會變快）孙蒙。

mongodb 的復制線程是主節(jié)點上的線程還是從節(jié)點上的線程项棠？

復制是主節(jié)點通知從節(jié)點還是從節(jié)點定時拉取呢？

主從復制是由從節(jié)點的線程發(fā)起的挎峦。通過監(jiān)聽主節(jié)點的oplog表的變化香追，并把oplog的entries pull到從節(jié)點進行回放。

oplog變化通知的方式類似于你在linux 下執(zhí)行一個tail -f 命令坦胶，一旦你tail的文件（oplog）有變化翅阵，馬上就會打印出來∏ㄑ耄或者在java里是類似于observable pattern掷匠。

1 投票節(jié)點疑問：

投票節(jié)點為什么不建議用？我看有的書上岖圈，如果是偶數(shù)的時候讹语，又增加一個投票節(jié)點，這樣就變成奇數(shù)了蜂科，比如3個數(shù)據(jù)節(jié)點顽决，2個投票節(jié)點短条。mongo為什么要設計投票節(jié)點？

2 集群部署問題：

1 從節(jié)點之間出現(xiàn)心跳不通才菠，但是都和主節(jié)點是通的茸时，這個會出現(xiàn)問題么？是不是網(wǎng)絡結構部署有問題赋访？

1）投票節(jié)點的最早設計初衷：需要奇數(shù)節(jié)點滿足一致性協(xié)議可都，但同時又想節(jié)省資源。為何不建議用蚓耽？降低的可用性（丟一個數(shù)據(jù)節(jié)點后風險很高）渠牲，無法使用更高的writeConcern（后續(xù)章節(jié)會講）來保證在主從切換的時候保證不丟失數(shù)據(jù)

2） 這種現(xiàn)象出現(xiàn)的可能性不大，你可以嘗試下畫下網(wǎng)絡拓撲步悠，具體到物理層鏈路签杈。如果真的出現(xiàn)了，應該是可以繼續(xù)工作的鼎兽。

選舉這塊答姥，如果有三個節(jié)點，leader節(jié)點掛了谚咬，剩余的兩個節(jié)點能對外提供服務嗎踢涌？能完成選舉不？

可以 - 剩下兩個滿足大多數(shù)（2）就可以正常完成選舉并工作序宦。

Mongodb2.4主從架構睁壁，從庫復制從主庫復制數(shù)據(jù)時會清空本地所有數(shù)據(jù)，然后再同步互捌？

如果是因為同步滯后潘明，超過oplog window大小，或者是數(shù)據(jù)庫損壞秕噪，或者是剛加入主庫钳降，都需要執(zhí)行initial syn的操作，這個就會清空本地庫再同步腌巾。

請問下有關選舉過程：對于保證大多數(shù)選舉節(jié)點存活這一個條件遂填。

舉例有7個選舉節(jié)點，是不是意味著必須有4個節(jié)點以上存活才可以進行選舉澈蝙？如果有4個節(jié)點存活吓坚，但是存活節(jié)點是偶數(shù)個，是否可以完成RAFT算法完成選舉灯荧。還是說選舉節(jié)點必須是奇數(shù)個礁击？

選舉節(jié)點必須是奇數(shù)，過半數(shù)（4）才可以工作和選舉

第一個問題：關于復制集這塊的secondary是怎么從主庫來來取oplog的，實現(xiàn)的細節(jié)是什么哆窿？想了解這塊的出發(fā)點就是作為dba的話链烈，會經常遇到一些生產問題，需要從原理上解決問題挚躯？

第二個問題：在local下强衡，有幾個關于副本集的集合，這幾個集合是干什么用的码荔，排查問題的時候漩勤，這幾個表有什么作用？

第三個問題: 我有一個副本集目胡，現(xiàn)在對一個secondary進行了物理的熱備，之后链快，想把這個節(jié)點加入現(xiàn)有集群,是只需要配置參數(shù)文件誉己，add加入副本集就可以嗎？如果可以加入副本集的話域蜗，他是通過哪個集合來判斷從哪個時間點開始來取oplog的巨双？

第一個問題你可以先看下這篇博客：

https://www.cnblogs.com/Joans/p/7723554.html

如果進一步了解的話，源碼也可以嘗試閱讀下

第二個問題也在上面的文章里有提及

第三個問題：可以的霉祸，但是要通過對local庫下面的一些表做個手腳筑累。如果你用MongoDB的Ops Manager的話，它就提供這種方法來快速恢復一個從節(jié)點丝蹭。

https://docs.opsmanager.mongodb.com/v1.4/tutorial/use-restore-to-seed-secondary/

其中關鍵的集合是system.replset 以及oplog.rs慢宗。 system.replset必須包含對應的配置（和其他節(jié)點一致）和時間戳。oplog.rs必須包含至少一條和主節(jié)點oplog一樣的記錄用來匹配同步點奔穿。

請問下配置復制集的時候用IP+端口的方式可以嗎镜沽？

可以的 - 如果能用hostname最好

我們的生產環(huán)境只有一臺服務器，但有2個硬盤贱田。做一主一從副本集缅茉，有意義嗎？

意義不是很大男摧，你crash了一個進程蔬墩，另一個進程也是沒法正常服務（需要3個節(jié)點才可以有HA）。硬盤的容錯直接用RAID就可以耗拓。

請教一下采用多副本集后拇颅，主節(jié)點寫，其他復制集讀乔询，但有時候主會切換成其他副節(jié)點蔬蕊，導致訪問mongodb的端口變化，調用程序無法連接上之前主節(jié)點進行寫入操作，前端調用程序該如何處理岸夯？

“但有時候主會切換成其他副節(jié)點” 你是在同一臺服務器上起了幾個不同端口的實例麻献？這樣的復制集/副本集是沒有意義的。

這種場景是常見的猜扮，在mongo世界里勉吻。你的連接串要同時包含3個節(jié)點的IP：PORT，這樣在切主的時候mongo的驅動會自動連到下一個主節(jié)點旅赢，你的應用程序無需處理齿桃。

我有兩個問題：

1從節(jié)點是主動監(jiān)聽主節(jié)點的op log并拉取嗎？?

mongo 選舉的時候煮盼，怎么知道集群中一共有多少節(jié)點短纵？還有就是自己是和大多數(shù)節(jié)點互通的？

1: 是的僵控。

2: 配置香到。開始搭建集群時候就要配置一下（或者通過add方法增加節(jié)點）

在做復制架構是在現(xiàn)有的環(huán)境做，這樣是會自動將現(xiàn)有的節(jié)點設置為主嗎报破？

還是要將現(xiàn)有節(jié)點數(shù)據(jù)同步到新節(jié)點上悠就。還是要在初始化的時候指定優(yōu)先級？

順序是：

1） 關掉mongo 服務

2）以復制集模式重新啟動mongo（加replSet 參數(shù))

3) 初始化復制集

4）增加第二（三）個節(jié)點（新的節(jié)點）

5） 等待initialSync 完成

這個時候你的原來的節(jié)點會是主節(jié)點充易。

我有多個復制集梗脾，當我想提升讀能力的時候。

是不是在讀的時候盹靴，要動態(tài)切換這些復制集的地址炸茧？

如果可以接受從節(jié)點讀，那么可以使用 readPreference: secondary/nearest (后續(xù)有講如何使用）稿静。這種方式可以使用更多的節(jié)點來支持讀操作宇立。

復制集和分片機制有什么區(qū)別？

我們可以對數(shù)據(jù)分片到不同機器上的同時保留復制集嗎自赔？部署配置方式有區(qū)別嗎妈嘹？

復制集提供高可用，分片集在此基礎上橫向擴充绍妨，增加系統(tǒng)對數(shù)據(jù)量/并發(fā)量的支持润脸。分片集由2個或多個復制集組成。

我在搭建集群的過程中遇到一個問題他去。?

如果我集群中的所有節(jié)點都設置了密碼毙驯，在使用rs.add("host:port")時會報沒有權限。此時我該如何解決呢灾测？

可能的問題：

1. 沒有為各個節(jié)點配置KeyFile爆价，或者

2. 啟用認證之后沒有創(chuàng)建管理員賬戶。rs.add()需要權限才能執(zhí)行。

3.不能用local 庫铭段。那個是系統(tǒng)保留的骤宣。用任意其他庫都可以。如 use test

試過用mysql 做讀寫分離序愚，開了binlog做主從同步憔披。遇到一種情況，主庫寫太頻繁(load file操作爸吮，沒有事務)芬膝，從庫同步延遲越來越大。

oplog的原理是否也是記錄成文件之后傳輸?shù)綇墓?jié)點形娇，由專門線程回放锰霜，mongodb是否也會出現(xiàn)這種問題？

oplog 和 binlog類似桐早。并且在壓力超大的時候癣缅，也有可能在從節(jié)點造成一些延遲。當然mongodb可以用多線程同時來回放勘畔。

講到MongoDB Ops Manager 集群管理平臺時所灸，說到該軟件支持 分片集群的備份丽惶。

請問分片集群的備份是什么意思炫七？mongodump 做不了嗎？

mongodump 能做全量備份钾唬，但是做不到一致性備份万哪。比如說，你想要一個半夜12點的備份抡秆，希望這個備份能夠還原那個時間點的分片數(shù)據(jù)庫的準確狀態(tài)奕巍。事實上，當你12點開始跑的時候儒士，可能要跑幾十分鐘到數(shù)小時才能備份完的止。這個時候又有持續(xù)的寫入（可能會在備份里，可能不會在着撩，取決于mongodump的讀取順序）诅福，所以你這個備份是屬于不一致狀態(tài)。

Ops Manager有自己獨特的機制來保證一個備份的多個分片之間數(shù)據(jù)是在一個時間點上一致的拖叙。

1 MongoDB鎖能否支持行級鎖氓润？

2. 64G內存的虛擬機 能否設置大于50%的wiredTiger cacheSizeGB?

?1）MongoDB采用的是MVCC機制，實際效果和行級鎖類似薯鳍。

2）可以的咖气，但是要考慮到mongodb除了緩存以外自身還需要額外內存，所以要適當給操作系統(tǒng)和mongo本身留一些。

從課程目錄里沒有看到有介紹MongoDB的數(shù)據(jù)庫引擎的內容崩溪。在這個課程里是不會涉及這部分內容嗎浅役？

因為目前我們公司使用的單節(jié)點MongoDB數(shù)據(jù)庫，每隔一段時間就會被服務器的OOM殺掉悯舟，在網(wǎng)上搜索了下相關資料担租，設置了WiredTiger引擎可用的緩存大小，但并沒有起作用抵怎，從系統(tǒng)日志里還是能看到MongoDB在占用了5G左右的內存后被OOM殺掉奋救。

MongoDB不僅僅是WiredTiger 緩存占據(jù)內存，除了緩存外反惕，還有連接管理尝艘，聚合計算，排序等都會用到姿染。

另外你可以注意下swap有無配置背亥。配置swap可能可以緩解OOM的問題。

第三范式的理由是什么呢悬赏？是因為節(jié)省數(shù)據(jù)庫空間嗎狡汉？

因為我感覺只有一個group的表然后有name, description和一組contact_id的數(shù)組也可以把？中間抽離一個contactGroup的意義何在呢闽颇？

第三范式是關系設計的實踐盾戴。

節(jié)省空間是一個很大的驅動 - 關系型理論出來的時候，1GB硬盤需要10萬美元的價格兵多。

數(shù)據(jù)一致性也是第三范式的一個目標尖啡。

你說的那種方式就是MongoDB的設計模式了。內嵌數(shù)組剩膘。

mongodb除了collection之外還有一個功能可以存附件衅斩，比如文件，視頻怠褐，音頻等畏梆。這個是和普通關系型數(shù)據(jù)庫有區(qū)別的地方吧，還有就是以前面試的時候奈懒，面試官也拿mongodb和fastdfs提問奠涌，兩者有什么區(qū)別，老師你可以用之前的項目經驗解答下么筐赔？

MongoDB的GridFS 不是一個真正的filesystem铣猩。

它其實是一個api sugarcoating。實現(xiàn)是在驅動端（不是mongodb服務器）茴丰，提供一個字節(jié)流的API达皿， 允許你把二進制文件通過這個接口提交給MongoDB 驅動天吓，或者從這個接口讀取二進制文件流。然后驅動會把這個文件分塊峦椰，每一塊作為一個mongodb的文檔插入到集合里龄寞。 當你需要的時候，mongodb驅動會把所有相關的切塊讀出來汤功，拼成一整個文件物邑，返回給應用程序。

所以這個不是真的文件系統(tǒng)滔金，只是提供了一個虛擬的文件接口供應用進行文件存儲和讀取色解。優(yōu)點是可以用到mongo的分布式能力，做海量的二進制文件管理和高可用等餐茵。

在學習過程中遇到一個概念Tailable Cursor科阎，這個應該怎么理解呢？

Linux 有個命令叫tail，如果你理解那個的用法，就知道這個名詞的由來了框产。

tail -f debug.log

這個命令會打印debug.log 的內容，然后不會退出错英，會在那里監(jiān)聽debug.log文件是否有新的日志寫入，一旦有新的隆豹，就會馬上在控制臺打印出來椭岩。

使用tailable cursor, 你的程序不會退出，讀完cursor最后一條以后會block噪伊，等待下一條數(shù)據(jù)過來后繼續(xù)簿煌。很多時候可以用來做一些類似Java里面 observer pattern的事情或者傳統(tǒng)數(shù)據(jù)庫里觸發(fā)器的事情氮唯。

使用的mongo是4.0.11版本的鉴吹，架構是分片集群，現(xiàn)在問題是惩琉，默認的最大連接數(shù)不夠用的豆励，819，怎么調優(yōu)最大連接數(shù)瞒渠？

有可能是和ulimits相關良蒸。你看下這個

https://docs.mongodb.com/manual/reference/ulimit/

日志、journal伍玖、oplog 這三個有什么聯(lián)系與區(qū)別呢嫩痰？

日志： 這個是一個比較通用的概念，可以包括你說的所有（journal,oplog,以及server日志）窍箍。

具體一點來說串纺， journal日志是數(shù)據(jù)庫的crash recovery手段丽旅。通常的做法是把數(shù)據(jù)庫內的數(shù)據(jù)塊修改，提前用文件順序寫方式刷到盤上纺棺，然后再去真正的提交數(shù)據(jù)的修改榄笙。這樣的目的是在服務器宕機的時候，內存中被丟失的數(shù)據(jù)可以在恢復過程中從journal 日志文件中讀回來祷蝌。

Oplog也是記錄的數(shù)據(jù)庫的操作日志茅撞，但是記的是邏輯操作命令。主要的目的是用于節(jié)點之間復制數(shù)據(jù)巨朦，而不是上面journal主要是用來recover crash米丘。

還有一種就是mongod.log，這個就是一個文本文件糊啡，記錄數(shù)據(jù)庫系統(tǒng)的正常運行和錯誤信息等等蠕蚜。

Mongo 落盤的時候，有用到文件系統(tǒng)的 Page Cache 機制嗎悔橄？

當有一條數(shù)據(jù)更新的時候是先寫到內存靶累，然后是Page Cache 最后是 硬盤嗎？

j 這個參數(shù)是代表寫到 Page Cache 還是硬盤呢癣疟？

j:1 表示Journal 日志刷盤挣柬，所以就是要寫文件到硬盤。

正常數(shù)據(jù)只是寫到內存的Cache（不是操作系統(tǒng)的cache睛挚，而是WiredTiger自己管理的Cache）邪蛔，然后異步刷盤。

mongodb事務的默認隔離級別是什么扎狱？

默認是read uncommitted侧到。

正常情況都不會有問題，除了發(fā)生宕機的時候淤击，這個可能會有問題 - 你讀到的一條數(shù)據(jù)可能會在宕機的時候被回滾掉匠抗。這種事情概率很小，發(fā)生了可能問題也不算特別嚴重污抬，很多場景可以接受汞贸。如果要求比較高，那么需要用 readConcern: majority 來提高隔離級別印机。

按照mongodb復制集選舉規(guī)則矢腻，有最新數(shù)據(jù)的會第一優(yōu)先被選為主節(jié)點

mongo是否可以在服務器端配置 majority write concern ，跟 j : true 射赛？

服務器端無法配置多柑。

你可以在Connection String上設置，這個一般是全局統(tǒng)一的設置楣责。

例子：mongodb://db0.example.com,db1.example.com,db2.example.com/?replicaSet=myRepl&w=majority&wtimeoutMS=5000

詳細文檔：

https://docs.mongodb.com/manual/reference/connection-string/

oplog是在內存中還是在磁盤上呢竣灌？?

每一次寫操作都會事務的記錄oplog?

oplog和就是一個MongoDB的collection 诫隅，都是存儲在磁盤上的。 對oplog的操作只是順序追加寫入帐偎，所以效率相對來說會高不少逐纬，相比于普通collection 的隨機讀寫。

每一次增刪改都會記錄相應的oplog削樊，并且對oplog的操作和數(shù)據(jù)表的寫入是同一個原子事務的豁生。

為什么說寫入多數(shù)集群才算安全呢？

寫入多數(shù)節(jié)點后漫贞，即時一個節(jié)點數(shù)據(jù)失效/不可用甸箱，你的數(shù)據(jù)還在另外一個節(jié)點上。是從這個角度迅脐。

請問怎樣限制 MongoDB 使用的總內存大猩种场？

32GB只是控制數(shù)據(jù)的緩存空間大小谴蔑。MongoDB服務器本身還需要內存來進行工作豌骏，如管理TCP連接，聚合隐锭、排序運算等窃躲。

chunk過程中各個分片上的oplog是會變化的嗎？這時候oplog跟分片上的數(shù)據(jù)能對應起來嗎钦睡？

會產生日志蒂窒。日志里有個特殊字段會標記出來是來自于chunk migration

change stream是如何觸發(fā)微服務的？比如庫存低于一定閾值后荞怒，觸發(fā)Java服務發(fā)送郵件

可以看這個例子：

https://github.com/spring-projects/spring-data-examples/tree/master/mongodb/change-streams

MongoDB適合存儲車輛GPS信息嗎洒琢？比如十萬輛車，每輛車每十秒上傳一次GPS信息（時間褐桌，坐標衰抑，方向，位置撩嚼，速度等）停士，MongoDB可以支持這種量級的數(shù)據(jù)嗎挖帘？還要考慮車輛位置實時監(jiān)控完丽，歷史時間段軌跡查詢等應用。

這個有非常多的案例拇舀。比較著名的是有最大的一個共享單車逻族，國內最大的汽車制造廠之一，以及最著名的電動車廠都是用mongo來記錄車輛GPS位置骄崩。放心去用吧聘鳞。

請問MongoDB復制集的連接數(shù) 和機器的配置應該怎么換算薄辅？怎么樣達到合理的連接數(shù)？

可以參考下這個文檔：

https://docs.atlas.mongodb.com/connection-limits/index.html

mongodb atlas云服務里面的規(guī)格和AWS機器規(guī)格對應：

M30 m4.large

M40 m4.xlarge

M50 m4.2xlarge

M60 m4.4xlarge

請問MongoDB的用戶是在庫上來配置的嗎抠璃，還是只是在admin庫里配置的站楚？

?理論上都可以 - 用戶可以在admin庫里，也可以在用戶庫里搏嗡。我們一般建議建在admin庫里方便統(tǒng)一管理

在MongoDB中怎么設置本地時間窿春，在查詢時間，顯示的時間比本地時間慢8個小時采盒？

?目前只支持格林威治時間旧乞。。磅氨。沒法設置尺栖。

MongoDB集群分片數(shù)據(jù)分配不均衡，怎么辦 烦租？

少數(shù)不均衡不是問題（比如說5-10% 的差別）延赌。多了不均衡，要看看是不是有下面問題叉橱？

1） Jumbo chunk

2） balancer 是不是停了皮胡？ sh.getBalancerState()

3) 寫入太頻繁，超過IO能力

數(shù)據(jù)量不是很大赏迟，如果要支撐百萬并發(fā)屡贺，一般要如何設計，大概要多少個節(jié)點锌杀，用復制集還是分片集甩栈？

官方的建議不管讀還是寫，都用分片來解決糕再。百萬級的并發(fā)算是很大了量没，如果是以查為主的讀操作占絕大多數(shù)，那么一個節(jié)點理論上支撐10萬以上并發(fā)是可以的突想，當然必須是那種32/64 核高CPU的物理服務器殴蹄。 Oppo的同學分享過單集群支撐100萬+并發(fā)，該集群由14個分片組成猾担，14x3共42臺機器

看視頻得知configsrv節(jié)點很重要袭灯，它保存了分片集群的元數(shù)據(jù)。

如果這個節(jié)點的數(shù)據(jù)因為一些原因損壞绑嘹、丟失了稽荧，那集群里的各個分片還能重新組成一個新的分片集群嗎？

各個分片的數(shù)據(jù)理論上是互不重疊的工腋，所以如果配置服務器壞的話姨丈，你將無法組成一個新的分片集群畅卓，但是你的數(shù)據(jù)可以合并起來組成非分片的集群。

當然蟋恬，考慮到分片集群某一時間點會有正在分片之間遷移的數(shù)據(jù)翁潘，這個數(shù)據(jù)合并還是有點風險。

所以你的配置服務器歼争，也是需要3個節(jié)點來保證數(shù)據(jù)的可靠性唐础。

mongodb還需要考慮分庫分表嗎，如果要考慮一般是在什么數(shù)量級別才分呢矾飞？

一般原則是不需要一膨。

如果你的應用場景用不到數(shù)據(jù)合并（連統(tǒng)一報表都不需要），并且數(shù)據(jù)量級在10億級以上洒沦，可以考慮作為一個特殊優(yōu)化手段做分表豹绪。

數(shù)據(jù)大小與機器配置有沒有經驗換算方式，比如1TB數(shù)據(jù)申眼，1主2從復制集瞒津，單臺服務器需要多大的配置，CPU括尸、內存巷蚪，還是需要模擬壓測？

官方沒有標準算法 - 根據(jù)workload的不同濒翻，硬件配置可以差別很大屁柏。

你可以參考MongoDB Atlas上面有個機器大小可以支持的Connections，所以從應用要支持的連接數(shù)有送，可以做一個反推淌喻。但是并不考慮你的數(shù)據(jù)量，所以只是個概括估計雀摘。

https://docs.atlas.mongodb.com/connection-limits/index.html

mongo分片集群如何實現(xiàn)讀寫分離裸删？需要配置哪些？可以提供一些資料查看嗎阵赠？

分片的讀寫分離和復制集的是一樣機制涯塔。可以查閱一下MongoDB read preference清蚀。參數(shù)可以直接給到mongos連接串匕荸。

視頻課程相關內容在這里

https://time.geekbang.org/course/detail/100040001-176897

我們生產使用的是分片模式，但是有一個集合沒有建片鍵轧铁，這個集合現(xiàn)在太大了占了7.4TB

1：現(xiàn)在怎么建片鍵每聪，可以建嗎？

2：建了片鍵之后會不會影響之前的數(shù)據(jù)查詢

1）可以齿风，直接用shardCollection就可以

2）不會药薯。

數(shù)據(jù)均衡可能會花很長時間（數(shù)天），這是正常的救斑。

沒有分片的集合是會隨機找個shard 復制集存嗎童本？

mongos在你新建庫的時候會為你的庫挑一個“primary shard”，所有未分片的集合都會在這個shard里面脸候。挑選的規(guī)則就是看哪個分片相對數(shù)據(jù)量小一點穷娱。

mongos configsvr 是否需要高內存 多核心的服務器，這2個服務能部署在同一個服務器上面么运沦？

config server通常有1~2c就可以,內存也不用大泵额，通常4G就可以。

mongos 因為要承接很多連接處理携添，一般建議CPU還是有給夠嫁盲，可以和mongod參考。因為它不緩存數(shù)據(jù)烈掠，所以內存也可以不用太大羞秤。可以參考mongod的一半左敌。

有一套環(huán)境config改完端口shard不能啟動了瘾蛋，還去連修改之前的端口。

為什么shard啟動的時候會去連config矫限？shard從哪里讀取config的信息哺哼？如何修改？

config上面存著分片的重要元數(shù)據(jù)（如chunk分布）叼风，沒有config server 分片集群無法工作的幸斥。shard server會建立到configserver的連接(正常端口）來獲取并緩存配置數(shù)據(jù)。

改完端口以后咬扇，config 復制集是否正常甲葬？你有重新啟動mongos 和 shard mongod 實例嗎？

所有操作必須要使用mongos懈贺。不能直接使用分片主節(jié)點经窖。直接操作主節(jié)點僅僅限于數(shù)據(jù)庫故障恢復

有的庫我不分片，目前我有2個分片集(A和B)梭灿，然后我創(chuàng)建一個新數(shù)據(jù)庫画侣，怎么指定其在分片集B上面？

db.adminCommand( { movePrimary : "your_dbname", to : "shard0001" } )

https://docs.mongodb.com/manual/reference/command/movePrimary/

?集群如何啟用驗證堡妒？

:集群如果啟用驗證的話配乱，需要用一個shared key文件，或者使用 X509 公鑰機制來進行集群間的互相認證。

可以先看下這個英文文檔搬泥，有問題再提桑寨。

https://docs.mongodb.com/manual/core/security-internal-authentication

1、如果兩個分片服務器性能不一樣忿檩，訪問和存儲可以權重類的設置嗎尉尾？

2、加入新的分片后燥透，集群里的分片數(shù)據(jù)會自動均衡到各分片嗎沙咏？比如首先只有第一個分片有30G數(shù)據(jù)，后面新增兩個分片班套，各分片會遷移10G數(shù)據(jù)嗎肢藐？

1）可以使用zone sharding方式來自己控制數(shù)據(jù)的分布。比如說分片1是16Core SSD吱韭，那你可以給它更多的數(shù)據(jù)吆豹。

2）是的，最后3個分片會各有10G左右

MongoDB備份只備份某一時刻的數(shù)據(jù)杉女。

如果發(fā)生宕機時用備份進行數(shù)據(jù)恢復也只能回復到備份的那一時刻瞻讽。那豈不是備完成到宕機這段時間的數(shù)據(jù)不就丟失了嗎？

這個就是RPO指標決定的熏挎。Recovery Point Objective. 如果是定期備份速勇，你的RPO就是你的備份間隔時間，比如說24小時坎拐。這樣的話你由可能丟失24小時的數(shù)據(jù)烦磁。

如果你希望RPO最小化，就要啟用實時備份oplog的方式哼勇。MongoDB官方提供OpsManager可以實現(xiàn)都伪，數(shù)據(jù)可以恢復到故障之前一分鐘。

然后积担，一般需要恢復的場景不是宕機陨晶。宕機這種比較常見的場景在MongoDB里面是通過復制集來解決的。一個節(jié)點宕機不影響業(yè)務帝璧，重啟就好了先誉。

備份恢復通常是出現(xiàn)一些數(shù)據(jù)問題，比如說的烁，有人刪庫跑路褐耳。

mongo的全量備份的時候，如果有插入或刪除數(shù)據(jù)呢渴庆，比如我在t0開始全量備份铃芦，t1時插入了一條數(shù)據(jù)雅镊，t2時備份到剛插入的數(shù)據(jù)，t3時完成備份刃滓，事后我用全量的備份數(shù)據(jù)加上期間的oplog的話仁烹，不就多插入一條數(shù)據(jù)了嗎？

oplog是有冪等性的注盈』挝＃回放的時候叙赚，t1 的數(shù)據(jù)+oplog的一條老客，合在一起，還是一條震叮。

請問mysql中的數(shù)據(jù)怎么遷移到mongodb呢胧砰？

對于少量數(shù)據(jù)(100M內) 和 大量數(shù)據(jù)(幾個T) 的處理方式分別是什么呢？

如果是一次性遷移苇瓣，直接導出到CSV文件然后使用mongoimport命令尉间。100MB或者幾個T都是這樣。

如果是持續(xù)遷移击罪，那需要一些專門的工具哲嘲，比如說我們公司的tapdata產品。

為什么需要分片集備份媳禁？

不是可以用mongodump進行全量備份嘛眠副？

這個方法可以做備份，但是不是最嚴格的竣稽。

嚴格的備份能夠提供指定時間點的恢復囱怕。比如說，如果你發(fā)現(xiàn)13：01分的時候有個誤刪操作毫别，使用好的分片備份機制娃弓，可以恢復到13：00的準確狀態(tài)。而通過mongodump是沒有這種保障機制的岛宦。

我們的生產環(huán)境近幾日有些數(shù)據(jù)刪掉了台丛，看還在oplog的覆蓋范圍內，但是我們之前沒做過全量備份砾肺，這個有什么辦法可以恢復嗎挽霉？

可以通過歷史數(shù)據(jù)備份+oplog 重放來恢復，抱歉恢復不了债沮。

副本集集群有通過物理備份+oplog實現(xiàn)任意點的恢復嗎炼吴，就是類似mysql的innobackupex+binlog的方式，有可參照的案例嗎疫衩？

可以的硅蹦，大致步驟是：

1）用snapshot或者關機復制文件方式進行全量備份

2）使用mongodump 備份 oplog 庫

3）恢復全量備份

4） 使用 mongorestore 的 --oplogFile --oplogLimit 參數(shù)來恢復指定的oplog 時間點

可以參考下面這個英文博客

https://alexmarquardt.com/2017/01/25/mongodb-point-in-time-restore

分片集群具體如何實施備份？

?停掉均衡器之后，各個節(jié)點通過定時任務備份（各個機器啟動備份時間點是否能夠絕對一致童芹，如果備份時間點存在幾秒的差別涮瞻，是否有致命風險？）

停掉均衡以后假褪，備份可以保證每個節(jié)點各自是準確的署咽。但是各個節(jié)點之間時間點很難保證在同一點上，所以每個節(jié)點恢復以后那個狀態(tài)不是完全同步的生音。這個沒有致命風險宁否，但是確實有數(shù)據(jù)不一致的可能性。如果要做到完全一致缀遍，需要使用MongoDB 企業(yè)版 Ops Manager的分片備份功能慕匠。

mongodb啟動參數(shù)中的logpath指的是mongo系統(tǒng)日志文件路徑， 相當于mongodb配置文件中的systemLog.path

你可以配置MongoDB寫日志到以下目的地：

1） 本地文件 （命令行參數(shù)--logpath域醇，或者配置文件 systemLog.path)

2) syslog （命令行參數(shù) --syslog台谊，或者配置文件內的systemLog.syslog)

3) 標準輸出（不用任何參數(shù)，默認）

參見： https://docs.mongodb.com/manual/reference/configuration-options/#systemLog.path

分片的集群通過mongos連接建立的用戶是保存在哪里譬挚，config集群上面還是每個shard里面也保存锅铅？

config 集群

$? mongo -u reader -p "Reader@123"? --authenticationDatabase? admin?

上面的命令中, 一定要加上 --authenticationDatabase admin 否則會導致 Authentication failed。

如果黑客mongo連接進去然后創(chuàng)建個超級用戶再登錄這種情況怎么辦?

啟動鑒權后减宣，你可以無密碼登錄進去盐须，但是只能做一件事：創(chuàng)建超級用戶。

這個事情也只能做一次（無密碼創(chuàng)建超級用戶）蚪腋，以后“黑客”再來丰歌，他就必須要登錄才能做創(chuàng)建用戶的事情。

所以你要做的事情屉凯，就是盡快創(chuàng)建那個超級用戶立帖。

mongoDB 可以定義類似 MySQL 的 create_time 和 update_time 字段嗎？

可以參考 $currentDate

https://docs.mongodb.com/manual/reference/operator/update/currentDate

這個ticket默認是128悠砚，一般調高這個值的時候需要參考哪些指標晓勇？比如物理機內存？cpu核數(shù)灌旧？節(jié)點數(shù)绑咱？有沒有相關經驗的最佳實踐分享下？

ticket一般只是個標志枢泰，如果發(fā)現(xiàn)用光描融，是因為你的物理資源不夠，主要是IOPS衡蚂，少數(shù)時候CPU窿克。這個時候不是調高tickt骏庸，而是優(yōu)化硬件資源。

最近做了個前端監(jiān)控分析的系統(tǒng)年叮，使用了MongoDB作為數(shù)據(jù)庫具被，現(xiàn)在每天的存儲記錄達到300W+條，查詢返回百萬級數(shù)據(jù)這塊不知道怎么優(yōu)化只损，老師有什么建議嗎一姿？

你需要對這些數(shù)據(jù)做pre-aggregation，按照時間顆粒度跃惫，獲得分鐘級平均數(shù)叮叹，小時級平均數(shù)，把他們事先存到庫里辈挂，給前段展現(xiàn)用衬横。這樣的話你就不需要返回大量的原始數(shù)據(jù)再在應用里做計算了裹粤。

聽完寫入操作的過程终蒂，有點好奇，oplog和journal日志能不能合并呢遥诉，我的理解的話就是oplog是個定容的集合拇泣，存放的記錄都是冪等操作，用于mongodb的復制集模式矮锈，從主節(jié)點復制到其他slave節(jié)點保證數(shù)據(jù)的一致霉翔，journal日志是用于mongodb crash之后恢復的一個日志。那crash恢復能不能也用oplog呢苞笨？

oplog記錄的是對數(shù)據(jù)庫的邏輯操作债朵， 在MongoDB里面用一個固定大小的普通集合來記錄，和其他的數(shù)據(jù)一樣瀑凝，默認增刪都是在內存里發(fā)生序芦。

journal 和其他數(shù)據(jù)庫類似，采用WriteAheadLog機制粤咪，用來提供對數(shù)據(jù)庫寫入操作的一致性和持久性保證谚中。它記錄的是要對數(shù)據(jù)物理區(qū)塊修改的一些動作。

Journal 日志和Oplog理論上都可以用來恢復寥枝，但是journal比較底層宪塔，直接操作存儲區(qū)，寫入和恢復效率要比oplog 日志高囊拜，所以通常數(shù)據(jù)庫都會采用專門的journal來做crash recovery.

如果剛開始只有一臺單體某筐，后面想擴容，做分片冠跷，搭復制集南誊，但是這臺單體上已經有相當?shù)臄?shù)據(jù)敢辩，那搭建復制集的時候是不是要先用dump等工具備份恢復一下數(shù)據(jù)？

對弟疆。使用dump/restore 可以加速這個過程戚长。如果不用dump也是可以，時間需要更多點怠苔，但是也是可以完成的同廉。

對于分片集群來說，應用端怎樣去配置連接串呢柑司？

只需要指定對應的幾個分片路由節(jié)點連接信息就可以了么迫肖，后面的副本集發(fā)生切換對路由節(jié)點或應用有沒有感知或者影響呢？

默認只需要配路由節(jié)點就可以攒驰。副本集切換是透明的蟆湖。

Retrywrite 只會重試一次嗎？如果重試第二次時新的primary還沒被選舉出來玻粪，是不是會寫失斢缃颉？

只會重試一次劲室， 會一直等到primary選舉成功才會試伦仍。如果30秒還沒選出來，這個寫操作就失敗了很洋。

30秒選不出來充蓝，這個大概率集群出故障了。

請問這一系列的課程喉磁，其中有一個課程(04 | MongoDB特色及優(yōu)勢)谓苟，有描述到有一個企業(yè)從1.x升級到4.X，影片時間落在9:48的位置协怒，透過滾動服務升級涝焙，透過replica set升級的升級。未來是否有課程會討論到這一塊斤讥，我想嘗試不下線的方式纱皆，從4.2升級到4.22，不知道是否有該實作的教學？

其實比較簡單的，假設ABC三個節(jié)點赘方，A是當前主節(jié)點，大致可以按照以下步驟：

- 停止C的mongo服務近迁，升級C的mongodb binary文件

- 重啟C服務，等待集群穩(wěn)定

- 停止B的mongo服務簸州，升級B的mongodb binary文件

- 重啟B服務鉴竭，等待集群穩(wěn)定

- 停止A歧譬，升級A的mongodb binary文件

- 重啟A，等待集群穩(wěn)定

這里有個中文翻譯

http://www.mongoing.com/docs/release-notes/3.0-upgrade.html

切換FCV是在所有節(jié)點上都切換還是只在主節(jié)點上切換搏存？

主節(jié)點上操作瑰步，會被復制到從節(jié)點。

MongoDB 壓測有什么好的工具和方法實踐嗎璧眠？

我們一般用 POCDriver / YCSB來做壓測缩焦。監(jiān)控的話用Ops Manager，可以整體看壓測過程中系統(tǒng)性能表現(xiàn)责静。

mongo是內存數(shù)據(jù)庫嗎袁滥？ 它的數(shù)據(jù)應該在保存到硬盤吧？

MongoDB 會在內存里操作數(shù)據(jù)灾螃，用異步刷盤方式题翻。所以你內存足夠大的話，可以近似的認為它有內存數(shù)據(jù)庫的性能腰鬼。

?事實上它有一種存儲引擎InMemory就是完全的內存數(shù)據(jù)庫了嵌赠。

電商網(wǎng)站的oracle部分不能用mongo替代嗎？

?完全可以垃喊。 你可以搜一下 MongoDB Cisco關鍵詞猾普。 幾百億的訂單都在MongoDB上處理，特別是4.0以后mongo支持了多文檔事務以后本谜。

mongodb為什么這么快，適用于秒級別的數(shù)據(jù)庫訪問（物聯(lián)網(wǎng)場景等）偎窘？

比如說redis雖然是單線程乌助，但是它基于了I/O多路復用的機制。

那mongodb呢陌知？因為它天然的支持了分布式么他托？

它的數(shù)據(jù)默認只是寫到內存就返回。數(shù)據(jù)的安全性通過同步到其他節(jié)點上和journal日志來保證仆葡。

沒有IO在里面赏参，響應時間自然就快。

怎么在mongo shell中修改MongoDB的配置參數(shù)沿盅？

db.adminCommand( { setParameter: 1, <parameter>: <value> } )

https://docs.mongodb.com/manual/reference/command/setParameter

mongoDB 數(shù)據(jù)庫存儲的時間相差八小時把篓，有什么設置可以調整嗎？還是必須要代碼轉一下腰涧？

?by design韧掩，沒法調整。這樣其實減少很多有bug的機會窖铡，就是要麻煩一點點轉一下

mongodb存儲文件疗锐，比如圖片和視頻坊谁，有什么方案嗎？

大視頻不太適合放mongodb滑臊。圖片可以考慮口芍。

如果真的存，直接用GridFS API就可以雇卷。還是挺方便的阶界。

MongoDB 專家之路的 3 個建議：

1、去 MongoDB 網(wǎng)絡大學注冊學習聋庵，并通過認證考試膘融。（https://university.mongodb.com）

2、通過官方文檔學習祭玉。（https://docs.mongodb.com）

3氧映、MongoDB 中文社區(qū)收集了很多 MongoDB 專家的精華文章和案例分享。（http://www.mongoing.com）