管理MongoDB：準備、監視和災難恢復

Ops Manager是由開發資料庫的工程師建立的，是執行MongoDB的最簡單方法，使操作團隊易於部署、監視、備份和擴充套件MongoDB。Ops Manager的許多功能在託管在雲中的MongoDB Cloud Manager服務中也是可用的。今天，雲管理器支援成千上萬的部署，包括從一臺到幾百臺伺服器的系統。使用MongoDB Enterprise Advanced執行部署的組織可以在Ops Manager和Cloud Manager之間進行選擇。

 

Ops Manager和Cloud Manager結合了最佳實踐來幫助保持被管理的資料庫健康和優化。它們通過單擊按鈕或通過API呼叫將複雜的手動任務轉換為可靠的自動化過程來確保操作的連續性：

 

部署。任何拓撲，任何規模

升級。幾分鐘之內，不用停機

擴充套件。擴充套件容量，而不需要關閉應用程式。

時間點，計劃備份。只需幾次單擊即可將完整的執行叢集恢復到任何時間點，因為災難是不可預測的。

效能警報。監視100多個系統度量並在系統降級之前獲得自定義警報。

Roll Out索引。通過逐個節點引入新的索引來避免對應用程式的影響——從第二索引開始，然後是降級的主索引。

管理區域。配置分片區域，以命令將哪些資料儲存在何處。

Operations Rapid Start服務為您的操作和開發團隊提供了執行和管理MongoDB的技巧和工具。此約定提供介紹性的管理員培訓和定製諮詢，以幫助您設定和使用MongoDB Ops Manager或MongoDB Cloud Manager（對於那些不想在內部維護自己的管理和備份基礎設施的操作團隊可用）。

部署與升級

Ops Manager在MongoDB系統中協調跨伺服器的關鍵操作任務。它通過安裝在每個伺服器上的代理與基礎設施通訊。伺服器可以駐留在公共雲或私有資料中心。Ops Manager可靠地編排管理員傳統上手動執行的任務——部署新叢集、升級、建立時間點備份、推出新索引和許多其他操作任務。

Ops Manager被設計成通過不斷評估狀態並根據需要做出調整來適應出現的問題。以下是具體內容：

• Ops Manager代理安裝在伺服器上（MongoDB將在其中部署），或者通過諸如Chef或Puppet之類的配置工具，或者由管理員安裝。
• 管理員為系統建立新的設計目標，或者作為對現有部署的修改（例如，升級、oplog大小調整、新分片），或者作為新系統。
• 代理定期向Ops Manager中央伺服器簽入並接收新的設計指令。
• 代理建立並遵循實現設計的計劃。使用複雜的規則引擎，代理會隨著條件的變化不斷調整他們的個人計劃。在許多故障場景（如伺服器故障和網路分割槽）面前，代理將修改其計劃以達到安全狀態。
• 幾分鐘後，系統被安全可靠地部署。

 

除了部署新資料庫之外，Ops Manager和Cloud Manager還可以“附加”或匯入現有的MongoDB部署並接管它們的控制。

 

除了初始部署，Ops Manager和Cloud Manager還可以通過新增分片和副本整合員來動態調整容量大小。其他維護任務，如升級MongoDB或調整操作日誌的大小，可以從幾十或數百個手動步驟減少到單擊按鈕，所有這些操作都具有零停機時間。

一個常見的DBA任務是在生產系統中推出新的索引。為了最小化對活動系統的影響，最佳實踐是執行滾動索引構建——從每個從節點開始，在與一個從節點交換角色之後，對原始主節點進行更改。雖然這個滾動過程可以手動執行，但是Ops Manager和Cloud Manager可以跨MongoDB副本集自動化該過程，從而減少操作開銷和由錯誤排序的管理過程導致的故障轉移。

管理員可以直接使用Ops Manager介面，或者從現有企業工具（包括流行的監視和編排框架）呼叫Ops Manager RESTful API。特定的整合提供了領先的應用程式效能管理（APM）工具。詳細資訊將在本指南的稍後部分介紹。

 

監測與容量規劃

系統性能和容量規劃是應該作為MongoDB部署的一部分處理的兩個重要主題。計劃的一部分應該包括建立資料卷、系統負載、效能和系統容量利用率的基線。這些基線應該反映您期望系統在生產中執行的工作負載，並且它們應該隨著使用者數量、應用程式特性、效能SLA或其他因素的改變而定期重新審視。

基線將幫助您理解系統何時按設計執行，以及何時開始出現可能影響使用者體驗質量或對系統至關重要的其他因素的問題。監視MongoDB系統的異常行為非常重要，以便能夠採取措施主動地解決問題。以下是監視MongoDB的最流行工具，並且還描述了應該監視的系統的不同方面。

 

使用Ops Manager與Cloud Manager監控

具有圖表、自定義儀表板和自動報警，Ops Manager跟蹤100個以上的主要資料庫和系統健康指標，包括操作計數器、記憶體和CPU利用率、複製狀態、開啟連線數、佇列和任何節點狀態。

圖4：Ops Manager：簡單、直觀、強大。單擊一次即可部署和升級整個叢集。

這些度量被安全地報告給Ops Manager和Cloud Manager，在瀏覽器中對它們進行處理、聚合、警告和視覺化，讓管理員可以輕鬆地實時確定MongoDB的健康狀況。檢視可以基於顯式的許可權，因此專案團隊可以限制許可權，僅訪問他們自己的應用程式，而系統管理員可以監視組織中的所有MongoDB部署。

從MongoDB 3.4開始，Ops Manager允許每隔10秒收集一次遙測資料，高於之前最小的60秒間隔

可以回顧歷史的表現，以便建立業務基線和支援能力規劃。通過Ops Manager RESTful API，與現有監視工具的整合也很簡單，使來自Ops Manager的深刻了解成為跨操作的統一檢視的一部分。

Ops Manager允許管理員在關鍵指標超出範圍時設定自定義警報。可以針對影響單個主機、副本集、代理和備份的一系列引數配置警報。警報可以通過SMS、電子郵件、網路鉤子、Flowdock、HipChat和Slack傳送，或者整合到現有的事件管理系統（如PagerDuty）中，以便在潛在問題升級到成本高昂的中斷之前主動警告它們。

如果使用Cloud Manager，還可以與MongoDB支援工程師共享對監視資料的訪問，從而通過消除在不同團隊之間傳送日誌的需要，提供快速的問題解決方案。

圖5：Ops Manager提供MongoDB部署的實時和歷史可見性。

 

硬體監控

Munin node是一個開源軟體程式，它監控硬體並報告磁碟和RAM利用率等指標。Ops Manager可以從Munin節點收集此資料，並將其與Ops Manager儀表板中可用的其他資料一起提供。雖然每個應用程式和部署都是唯一的，但是使用者應該為磁碟利用率的高峰、網路活動的主要變化以及平均查詢長度/響應時間的增加建立警報。、

mongotop

mongotop是與MongoDB一起提供的實用程式。它跟蹤並報告MongoDB叢集的當前讀寫活動。mongotop提供集合級別的統計資料。

mongostat

mongostat是與MongoDB一起提供的實用程式。它顯示了MongoDB系統中所有伺服器的實時統計資料。mongostat提供了所有操作的全面概述，包括更新、插入、頁面錯誤、索引丟失以及系統健康的許多其他重要度量的計數。mongostat類似於Linux工具vmstat。

MongoDB Compass

嘗試解析文字輸出可以顯著增加解決查詢效能問題的時間。MongoDB Compass現在被擴充套件為視覺化mongotop和mongostat生成的相同的實時效能統計資料，允許DBA生成伺服器狀態和查詢效能的即時快照。

 

一些其他的流行工具

有許多流行的開源監控工具，MongoDB外掛可用於這些工具。如果使用WiredTiger儲存引擎配置MongoDB，則確保工具使用WiredTiger相容的驅動程式：

• Nagios
• Ganglia
• Cacti
• Scout
• Zabbix
• Datadog

 

Linux實用工具

其他的一些通用的使用工具可以用來監控MongoDB系統的不同方面：

• iostat： 用來統計儲存子系統的資訊
• vmstat： 用來統計虛擬記憶體的資訊
• netstat： 用來統計網路資訊
• sar：定期捕獲各種系統統計資訊並存儲它們以便分析

 

Windows實用工具

要監視的東西

Ops Manager和Cloud Manager可用於監視資料庫指定的度量，包括頁面錯誤、ops計數器、佇列、連線和副本集狀態。可以針對每個監控指標配置警報，以便在使用者遇到問題之前主動警告管理員潛在的問題。

應用程式日誌與資料庫日誌

應用程式日誌和資料庫日誌應該監視錯誤和其他系統資訊。為了確定應用程式中的活動是否最終負責系統中的其他問題，關聯應用程式和資料庫日誌非常重要。例如，使用者寫入的激增可能增加對MongoDB的寫入量，這反過來又會壓倒底層儲存系統。如果沒有應用程式和資料庫日誌的相關性，那麼可能需要花費更多不必要的時間來確定，是應用程式寫入的增加，還是MongoDB中執行的某些程序導致的。

在發生錯誤、異常或意外行為的情況下，在開啟支援案例時，應該儲存日誌並將其上傳到MongoDB。在主副本整合員和從副本整合員上執行的mongod程序以及mongos和config程序中的日誌將使支援團隊能夠更快地根除任何問題。

頁面錯誤

當工作集不再適合記憶體，或者其他操作已經將工作集資料從記憶體中移出時，MongoDB系統中的頁面故障量可能會激增。頁面錯誤是MongoDB系統正常操作的一部分，但是應該監視頁面錯誤的數量，以便確定工作集是否正在增長到記憶體大小已經不適合的級別了，以及是否有合適的備選方案，如跨多個伺服器增加記憶體或分片。在大多數情況下，MongoDB系統中問題的根本問題往往是頁面錯誤。還要使用指南前面討論的工作集估計器。

磁碟

除了記憶體之外，磁碟I/O對於MongoDB系統也是一個關鍵的效能考慮因素，因為寫操作是日誌記錄的，並且有規律地被髮送到磁碟。在沉重的寫負載下，底層磁碟子系統可能變得不堪重負，或者其他程序可能與MongoDB爭用，或者RAID配置可能不足以滿足寫的操作。其他潛在的問題可能是根本原因，但是症狀通常通過iostat可見，表現為用於寫操作的磁碟利用率高和佇列高。

CPU

各種各樣的問題可能觸發高CPU利用率。在大多數情況下，這可能是正常的，但如果觀察到高CPU利用率而沒有其他問題，如磁碟飽和或頁面故障，則系統中可能存在不尋常的問題。例如，具有無限迴圈的MapReduce作業，或者對來自工作集的大量文件進行排序和過濾的查詢，如果沒有良好的索引覆蓋率，可能導致CPU出現峰值，而不觸發磁碟系統中的問題或頁面故障。

連線數

MongoDB驅動程式實現了連線池，以便於資源的有效使用。每個連線消耗1MB的RAM，所以要小心監視連線的總數，這樣它們就不會壓倒RAM，並減少工作集的可用記憶體。這通常發生在客戶端應用程式沒有正確地關閉它們的連線，或者特別是Java時，依賴於垃圾收集來關閉連線。

運算計數器

應用程式的利用率基線將幫助您確定操作的正常計數。如果這些計數開始顯著偏離您的基線，那麼它可能是應用程式中發生了更改或正在進行惡意攻擊的指示符。

佇列

MongoDB無法及時完成所有請求，則請求將開始排隊。健康的部署將顯示出非常低的佇列。如果度量開始偏離基線效能，例如由很高頻的頁面錯誤（MMAPv1）或長時間執行的查詢導致的，則來自應用程式的請求將開始排隊。因此，佇列是確定是否存在會影響使用者體驗的問題的最佳首選位置。

系統配置

在MongoDB部署過程中對硬體和軟體進行更改並不罕見。例如，可以替換磁碟子系統以提供更好的效能或增加的容量。當元件更改時，確保它們的配置適合於部署非常重要。MongoDB對作業系統和底層硬體的效能非常敏感，在某些情況下，系統配置的預設值並不理想。例如，檔案系統的預設預讀(readahead)可以是幾個MB，而MongoDB對接近32KB的預讀值(readahead )進行了優化。如果安裝新的儲存系統而不對預讀進行從預設設定到適當設定的更改，則應用程式的效能可能顯著降低。

 

分片平衡器

分片的目標之一是跨多個伺服器均勻地分佈資料。如果伺服器資源的利用率在伺服器之間不是大致相等的，那麼可能存在部署有問題的底層問題。例如，選擇不當的片鍵可能導致不均勻的資料分佈。在這種情況下，大多數（如果不是全部）查詢將指向管理資料的單個mongod。此外，MongoDB可能正在嘗試重新分發文件，以便在伺服器之間實現更理想的平衡。雖然重新分發最終將導致更理想的文件分發，但是與重新平衡資料相關的大量工作以及該活動本身可能妨礙實現期望的效能SLA。通過執行db.currentOp()，您將能夠確定叢集當前正在執行什麼工作，包括跨分片重新平衡文件。

在MongoDB 3.4中，平衡器支援並行資料遷移。多個節點對可以同時執行平衡遷移，從而顯著提高大型叢集中的平衡器吞吐量。此外，WiredTiger的均衡器節流現在預設情況下是關閉的，從而加速了10倍的遷移效率。

如果在部署過程中確定應該使用新的片鍵，則需要用新的片鍵重新載入資料，因為片鍵的指定和值是不可變的。為了支援使用新的片鍵，可以編寫一個指令碼來讀取每個文件、更新片鍵並將其寫回資料庫。

複製滯後

複製滯後是對主複製整合員進行寫操作以複製到從成員所需的時間。少量的延遲是正常的，但是隨著複製滯後的增長，可能會出現顯著的問題。複製延遲的典型原因包括網路延遲或連線性問題，以及磁碟延遲，例如從裝置的吞吐量低於主裝置的吞吐量。

 

Config伺服器可用性

在分片環境中，需要執行三個或更多個config伺服器。config伺服器對於理解文件在分片之間的位置至關重要。在這種情況下，資料庫將繼續執行，但是平衡器將無法移動塊，並且其他維護活動將被阻塞，直到所有三個config伺服器都可用。

預設情況下，Config伺服器被部署為MongoDB副本集模式。Config伺服器副本集可以跨越三個以上的資料中心，最多支援50個副本整合員，從而提供更高水平的可用性和更低的跨區域延遲。檢視文件以瞭解更多資訊。