災難恢復：備份與恢復

備份和恢復策略對於保護任務關鍵型資料免受災難性故障或人為錯誤（例如程式碼錯誤或意外丟棄集合）是必需的。有了備份和恢復策略，管理員可以在沒有資料丟失的情況下恢復業務操作，並且組織可以滿足法規和遵從性要求。定期備份還有其他優點。備份可用於為開發、階段或QA部署新的環境，而不影響生產系統。

Ops Manager和Cloud Manager備份是連續維護的，僅比作業系統晚幾秒鐘。如果MongoDB叢集出現故障，最近的備份只是稍微落後了一會兒，從而最小化了資料丟失的風險。Ops Manager和Cloud Manager是唯一的MongoDB解決方案，它們提供副本集的實時備份和分片叢集的叢集範圍的快照。您可以快速而安全地恢復到您需要的精確時刻。Ops團隊可以使用Ops Manager和Cloud Manager可靠和安全地自動進行資料庫恢復。只需幾次簡單的點選即可構建完整的開發、測試和恢復叢集。操作團隊可以只針對指定集合而不是整個資料庫來配置備份，從而加速備份並減少所需的儲存空間。

因為Ops Manager只讀取操作日誌，所以正在進行的效能影響最小——類似於向副本集新增附加副本。

通過使用MongoDB Enterprise Advanced，您可以部署Ops Manager以控制本地資料中心中的備份，或者使用Cloud Manager服務，該服務提供具有現收現付模式的完全管理的備份解決方案。專用MongoDB工程師在24x365基礎上監視使用者備份，在出現問題時向操作團隊發出警報。

Ops Manager和Cloud Manager不是備份MongoDB的唯一機制。其他選擇包括：

• 檔案系統副本
• 用MongoDB打包的mongodump工具

檔案系統備份

檔案系統備份（如Linux LVM提供的檔案系統備份）可以快速有效地建立檔案系統的一致快照，這些快照可以複製用於備份和還原目的。對於具有單個副本集的資料庫，可以暫時停止操作，以便通過發出db.fsyncLock()命令來建立一致的快照（如果日誌與MMAPv1的資料檔案位於同一裝置上，則不需要鎖定資料庫）。這將閃爍所有掛起的對磁碟的寫入，並鎖定整個mongod例項，以防止額外的寫入，直到用db.fsyncUnlock()釋放鎖為止。

有關如何使用檔案系統快照建立MongoDB備份的更多資訊，請參閱MongoDB文件中的備份和恢復檔案系統快照。

只有Ops Manager和Cloud Manager提供了在所有分片之間進行一致備份的自動化方法。

有關分片環境中的備份和還原的更多資訊，請參閱關於備份和還原分片叢集的MongoDB文件頁面和關於用檔案系統快照備份分片叢集的教程。

mongodump

mongodump是與MongoDB捆綁的工具，它執行MongoDB中資料的實時備份。mongodump可用於dump整個資料庫、集合或查詢結果。mongodump可以通過dump在dump期間建立的操作日誌條目，然後在mongorestore期間重放它，從而生成一個數據轉儲，該資料dump會在短時間內反轉，mongodump是一個從mongodump生成的BSON資料庫轉儲中匯入內容的工具。

MongoDB與外部監控解決方案的整合

Ops Manager API通過以程式設計方式訪問自動化特性和監視資料，提供與外部管理框架的整合。

除了Ops Manager之外，MongoDB Enterprise Advanced還可以向SNMP陷阱報告系統資訊，支援通過外部監控解決方案進行集中資料收集和聚合。檢視文件以瞭解關於SNMP整合的更多資訊。

APM整合

許多操作團隊使用應用程式效能監視（APM）平臺從單個管理UI獲得對其完整IT基礎設施的全域性監督。可以快速識別和隔離影響客戶體驗的風險問題，以指定元件——是否可歸因於裝置、硬體基礎設施、網路、API、應用程式程式碼、資料庫等等。

圖6：整合到應用程式效能的單個檢視中的MongoDB

MongoDB驅動程式包括向APM工具公開查詢效能指標的API。管理員可以監視在每個操作上花費的時間，並識別需要進一步分析和優化的執行緩慢的查詢。

此外，Ops和Cloud Manager現在提供與New Relic平臺的打包整合。APM可以訪問Ops Manager的關鍵度量以進行視覺化，從而能夠監視MongoDB的健康狀況，並與應用程式區域的其他部分相關聯。

如圖6所示，概要度量在APM的UI中呈現。管理員還可以針對監視資料執行用於分析的New Relic Insights，以生成提供關鍵效能指示符（KPI）的實時跟蹤的儀表板。

安全

與所有軟體一樣，MongoDB管理員必須考慮MongoDB部署的安全性和風險。對於風險緩解，沒有神奇的解決方案，維護安全的MongoDB部署是一個持續的過程。

深度防禦

建議使用深度防禦方法來確保MongoDB部署的安全性，並且它解決了許多管理風險和減少風險暴露的不同方法。

深度防禦方法的意圖是使您的環境分層，以確保沒有可利用的單個故障點，從而允許入侵者或不信任方訪問MongoDB資料庫中儲存的資料。減少開發風險的最有效方法是在可信任的環境中執行MongoDB、限制訪問、遵循具有最少特權的系統、建立安全的開發生命週期以及遵循部署最佳實踐。

MongoDB Enterprise Advanced具有防禦、檢測和控制對MongoDB的訪問的廣泛功能，提供任何現代資料庫的最完整的安全控制之一：

• 使用者許可權管理。使用用於對資料庫、集合進行身份驗證和授權的行業標準機制控制對敏感資料的訪問，並低到文件中單個檔案的訪問級別。
• 審計。確保有監管和內部遵守。
• 加密。保護在網路上執行的資料，並在持久儲存中保持靜止。
• 管理控制。更快地識別潛在開發風險並減少其影響。

回顧MongoDB安全參考體系結構，以瞭解下面討論的每個安全特性的更多資訊。

認證

可以通過質詢/響應機制和x.509PKI證書從資料庫本身管理身份驗證，或者通過MongoDB Enterprise Advanced整合到外部安全機制，包括LDAP、Windows Active Directory和Kerberos。

授權

MongoDB允許管理員定義使用者或應用程式的許可權，以及在查詢資料庫時可以訪問哪些資料。MongoDB提供了配置粒度使用者定義的角色的能力，使得在訪問和管理資料庫的不同實體之間實現職責分離成為可能。

MongoDB 3.4擴充套件了對通過LDAP對使用者進行身份驗證的現有支援，現在包括LDAP授權。這使得儲存在LDAP伺服器中的現有使用者特權能夠對映到MongoDB角色，而無需在MongoDB本身中重新建立使用者。

審計

MongoDB Enterprise Advanced允許安全管理員為針對MongoDB（無論是DML、DCL還是DDL）的任何操作構造和更合適的審計跟蹤。例如，可以記錄和審計檢索到指定文件的使用者的身份以及在會話期間對資料庫所做的任何更改。可以將審計日誌以各種格式寫入多個目的地，包括寫入控制檯和syslog（JSON格式）以及寫入檔案（JSON或BSON），然後可以將審計日誌載入到MongoDB並分析以識別相關事件

加密

MongoDB資料可以在網路和磁碟上進行加密。

對SSL的支援允許客戶端通過加密通道連線到MongoDB。MongoDB支援FIPS 140-2加密時，執行在FIPS模式與FIPS驗證的加密模組。

可以使用以下方法保護靜止的資料：

• MongoDB加密儲存引擎
• MongoDB合作伙伴的證書資料庫加密解決方案，如IBM和Vormetric
• 應用程式本身的邏輯

使用加密儲存引擎，保護靜止資料現在成為資料庫的一個整體特徵。通過本地加密磁碟上的資料庫檔案，管理員消除了外部加密機制的管理和效能開銷。這個新的儲存引擎提供了額外的防禦級別，只允許具有適當資料庫憑證的人員訪問加密資料。

使用加密儲存引擎，使用以隨機加密金鑰作為輸入並生成“密文”的演算法來加密原始資料庫“純文字”內容，如果使用解密金鑰解密，則只能讀取“密文”。該過程對於應用程式是完全透明的。MongoDB支援多種加密演算法——預設是CBC模式下的AES-256（256位加密）。還支援GCM模式下的AES-256。加密可以配置為滿足FIPS 140-2的要求。

儲存引擎使用單獨的金鑰加密每個資料庫。MongoDB中的金鑰包裝方案，用一個外部主金鑰，包裝每個伺服器的所有單獨的內部資料庫金鑰。加密儲存引擎支援兩個金鑰管理選項——在這兩種情況下，MongoDB外部管理的唯一金鑰是主金鑰：

• 通過金鑰檔案進行本地金鑰管理
• 通過KMIP協議與第三方金鑰管理裝置整合（推薦）

只讀、編譯檢視

在MongoDB 3.4中，DBA可以定義只公開來自底層集合的資料子集的非物化檢視，即適合指定檔案的檢視。DBA可以定義通過聚合在另一個集合或檢視上生成的集合的檢視。針對檢視授予的許可權是與授予基礎集合的許可權分開指定的。

檢視是使用標準的MongoDB查詢語言和聚合管道定義的。它們允許包含或排除檔案、遮蔽檔案值、調整、模式轉換、分組、排序、限制以及使用$lookup和$graphLookup連線資料到另一個集合。

您可以從文件中瞭解更多關於MongoDB只讀檢視的資訊。

本文如果對您有所幫助，歡迎請我喝杯咖啡^_^

支付寶

微信

支付寶掃一掃領紅包