Mongodb 筆記09

標籤：

備份

1. 只有在有信心能在緊急情況下完成迅速部署的情況下，備份才是有用的。所以，無論選擇了哪種備份技術，一定要對備份及恢複備份的操作進行練習，知道瞭然於心。

2. 通常情況下，應對複本集的非主節點(與主節點相對)進行備份。

3. 對伺服器進行備份

    1). 檔案系統快照：使用快照備份需要開啟日記系統。如果是對正在啟動並執行系統產生快照，那麼快照的資料內容本質讓相當於使用kill -9 命令強制終止後的資料內容。因此，mongod在啟動時會對日誌

         檔案進行重放，然後開始正常運行。

    2). 複製資料檔案：

         方法一：

         a. 鎖定資料庫，禁止任何寫入，並進行同步(fsync)，即將所有髒頁面重新整理至硬碟，以確保資料目錄中的檔案是最新的，且不會被更改。db.fsyncLock()

         b. 當fsynclock命令返回命令列後，複製資料目錄中的所有檔案到備份位置。在Linux中，可使用以下命令等：cp -R /data/db/*  /mnt/external-drive/backup

         c. 資料複製完成後，解鎖資料庫，使其能夠再次進行寫入操作：db.fsyncUnlock()

         注意，身分識別驗證和fsynclock命令存在一些鎖定問題。如果啟用了身分識別驗證，則在調用fsyncLock()和fsyncUnlock()期間不要關閉shell。如果在這期間斷開了串連，則可能無法進行重連，並不得不重啟mongod。

         fsyncLock()的設定在重啟後不會保持生效，mongod總是以非鎖定模式啟動。

         方法二：

         關閉mongod，複製檔案，然後重啟mongod。

    3). 恢複資料目錄備份：保證mongod沒有在運行，且所有待恢複的目錄為空白。將備份的資料檔案複製到資料目錄，然後重新啟動mongod。只要知道要複製哪些檔案，即可使用這種方式備份單獨的資料庫。

    4). 使用mongodump : 優點：可以備份單獨的資料庫、集合甚至集合中的子集              缺點：備份和恢複速度慢，在處理複本集時存在一些問題。

         如果要在同一台機器上運行mongod和mongodump，只需指定mongod運行時佔用的連接埠即可：mongodump -p 31000 mongodump會在目前的目錄建立一個轉儲目錄。

         在任何集合中，如果存在除_id 以外的其他唯一索引，則應該拒絕使用mongodump和mongorestore進行備份。

4. 對複本集進行備份：通常，應該對備份節點進行備份。這會為主節點減輕負擔，也可以在不影響應用的情況下鎖定備份節點(只要應用不向備份節點發送讀取請求)。

    可使用之前提到過的是那種方式中的一種，對複本集中的成員進行備份，但推薦使用檔案系統快照或複製資料檔案的方式。這兩種方式無需做任何修改。

5. 對分區叢集進行備份：在面對分區叢集時，我們更關注分塊的備份，即單獨備份設定管理員和複本集。在對分區叢集進行備份和恢複操作前，應先關閉均衡器。這是因為在過於混亂的環境中無法得到一份前後一致的快照。

    1). 備份和恢複整個叢集(不推薦)：

    2). 備份和恢複單獨的分區：更多時候，只需要恢複叢集中的某個單獨分區。如果不是很挑剔的話，可使用剛剛在前面提到單獨伺服器的處理方法進行備份恢複。

6. 使用mongooplog進行增量備份：我們只需要進行一次備份，然後使用oplog來備份這之後的所有操作。這種技術比之前體積的技術都要複雜，因此除非確實需要，否則應盡量選擇其他技術。

    

 

部署MongoDB

1. 設計系統結構

    1). 選擇儲存介質：如果只考慮效能，應按一下順序進行選擇：記憶體，固態硬碟，機械磁碟。

         a. 由於條件限制，一般標準的部署方案是使用較少的記憶體空間和較大的機械盤空間。這種情況下需注意，工作集大小應小於記憶體容量，同時應做好在工作集增長時進行裝置擴充的準備。

         b. 即使更快的機械硬碟，也不會使硬碟讀取時間縮短太多，所以沒有必要花太多時間在這種磁碟上。更多的記憶體和固態硬碟效果更好。

         c. 通常我們不能向已有的複本集中添加固態硬碟，如果複本集中存在機械硬碟的話。如果使用固態硬碟的機器成為主成員，並接管處理它所能處理的一切工作，則其他成員受速度所限，無法及時複製資料，從而被落

             在後面。因此，如果要引入固態硬碟的話，向叢集中增加一個新的分區不失為一種更好的選擇。

         d. 可以考慮用機械硬碟來記錄日誌，而用固態硬碟記錄資料。

    2). 推薦的RAID配置

         a. RAID: 獨立磁碟容錯陣列，舊稱廉價磁碟冗餘陣列，是一種可以讓我們把多塊磁碟當做單獨一個塊磁碟來使用的技術。可以使用它來提高磁碟的可靠性或效能，或二者兼有。

                      一組使用RAID技術的磁碟被稱為RAID磁碟陣列。

         b. RAID10：資料被分割以提升速度，又被複製鏡像以提高可靠性。

    3). MongoDB對於CPU的負載很輕。如需在記憶體和CPU間選擇一個進行硬體投資，一定要選記憶體。如需在速度和核心數間做出選擇，應選擇前者。相比更多的並行運算，MongoDB能更好地利用單一處理器上的更多周期進行運算。

    4). 選擇作業系統：64位Linux作業系統是運行在MongoDB的最好選擇。ContOS和RedHat企業版可能是最普遍的選擇。應使用最新發行的穩定版本，因為老舊的、存在缺陷的軟體包或核心有時會產生問題。

    5). 交換空間：應分配一小塊交換空間，以防止系統記憶體使用量過多，從而導致核心終止MongoDB的運行。然後，MongoDB通常並不會使用任何交換空間。

         MongoDB所使用的大部分記憶體都是"不穩定的"：只要系統因某些原因而請求記憶體空間，這部分記憶體中的記憶體就會被重新整理到磁碟中，然後元記憶體則被替換成其他內容。因此，書庫資料絕不應該被寫入交換空間，

         因為它首先會被重新整理磁碟。然而，MongoDB在需要對資料進行排序，即建立索引或進行排序操作時，會使用操作空間。在進行此類操作時，MongoDB會盡量不去使用過多記憶體，但如果同時進行很多這種操作，

         最終會使用到交換空間。如果應用程式在伺服器上用到了交換空間，則應想辦法重新設計應用程式，或者減少那台伺服器上的負載。

    5). 檔案系統：在linux系統上，推薦使用ext4或XFS檔案系統作為資料卷。具有一個能夠在備份時進行檔案系統快照的檔案系統是不錯的，但是會影響到效能。盡量避免使用NFS檔案系統。

2. 虛擬化：運用虛擬化技術可以方便地使用廉價的硬體來部署系統，並且能夠迅速做出擴充。然後，虛擬化也存在缺點，尤其是無法預知的網路和磁碟IO狀況。

    1). 禁止記憶體資源過度分派：

         a. 記憶體過度分區的設定決定了當前進程向作業系統請求過多記憶體時應採取的策略。基於這個設定，核心可能會為進程分配記憶體，哪怕那些記憶體當前是停用(期望的結果是，當前進程用到這段記憶體時

             它變成可用的)。這種核心向進程確保不存的記憶體行為，就叫做記憶體資源過度分派。這一特性使得MongoDB無法很好地運作。

         b. vm.overcommit_memory的值可能為0(讓核心來猜測資源過度分派的大小)，可能為1(滿足所有記憶體配置請求)，也可能是2(分配的虛擬位址空間做多不超過交換空間與一小部分資源過度分派的和)。將此值設為2所代表的

             意義最為複雜，同時也是最佳選擇。運行以下命令將此值設為2 ： $echo 2 > /proc/sys/vm/overcommit_memory      更改這一設定後無需重啟MongoDB 

    2). 神秘的記憶體：

    3). 處理網路磁碟的IO問題

         a. 不要將MongoDB託管在雲端

         b. 選擇能夠保證一定數量IOPS(IO Operations Per Second，每秒IO操作)的執行個體。

         c. 監視MongoDB所使用的卷。一旦某個卷的速度變慢，立即終止這一執行個體的運行，接著啟動一個使用另一個資料卷的執行個體。監控內容：IO利用率的峰值(MMS中的"IO延遲"),也缺失發生頻率的峰值，TCP丟包增長情況，

             MongoDB讀寫隊列的峰值。

    4). 使用非網路硬碟：臨時磁碟機是真正和虛擬機器(VM)所在的機器鍵存在物理串連的磁碟，所以並不存在很多網路儲存中出現的問題。這些磁碟是臨時的，不能用來儲存重要資料。

3. 系統配置：

    1). 禁用NUMA：禁用每個CPU都訪問記憶體中的所有內容。MongoDB 傾向於訪問更多的資料，哪怕效率低，而非高效地訪問一小部分資料。禁用NUMA是一個能夠提升效能的魔法按鈕，一定要按下它。它就像使用固態硬碟

         一樣，禁用NUMA可提升所有事物的效能。

         a. 如果可能的話，應通過BIOS禁用來禁用NUMA。 例如，如果在使用grub，可在grub.cfg中添加numa=off選項：kernel /boot/vmlinuz-2.6.38-8-generic root=/dev/sda ro quiet numa=off

         b. 如果系統無法在BIOS中禁用NUMA，則可在啟動mongod時使用以下選項：$ numactl --interleave=all mongod [options]   將這一命令添加到所有使用的初始化指令碼中。

         c. 禁用zone-reclaim_mode選項，可以把該選項認為是超級NUMA，它會將記憶體中的內容來回移動到CPU的本地內容：$ echo 0 > /proc/sys/vm/zone_reclaim_mode ，無需重啟mongod , 即可生效。

         e. 啟用NUMA後，主機上的MMS上會被顯示為黃色。禁用NUMA後，會變為藍色。

    2). 更智能地預讀取資料：預讀是一種最佳化手段，即作業系統從磁碟中讀取比實際請求更多的資料。這一最佳化的原理是：電腦所處理的大部分工作都是連續的，即如果載入一個視頻檔案的前20M內容，則接下來很可能需要

         用到緊隨其後的若干MB內容。於是，系統會從磁碟中讀取比實際請求更多的內容，並將其放到記憶體中，以方便隨後調用。

         a. MongoDB並非是典型的工作負載，設定預讀也是MongoDB系統中常見問題。MongoDB傾向於從磁碟中隨機讀取很多小塊的資料，所以預設的系統設定並不能很好的運作。如果預讀內容過多，記憶體中會逐漸充滿

             MongoDB沒有請求的內容，迫使MongoDB更多的訪問磁碟。

         b. 使用blockdev命令，可查看當前的預讀設定

         c. 可以通過--setra 選項更改預讀大小設定：$ sduo blockdev --setra 16 /dev/sdb3          推薦值是16到256之間。 

             預讀大小不應設得過小，否則讀取一個單獨的檔案則需要多次訪問磁碟。如文旦過較大(大於1M)，則應考慮預讀更多的內容。如果文檔較小，預讀的數值則應小一些，例如32。即使文檔非常小，也不要將預讀大小的值

             設為16以下。這會導致讀取索引資訊時效率低下。

         d. 需要重啟MongoDB才能使預讀設定生效。這是因為進程會在啟動時複製一份預讀大小的設定值，並一直按照該值運作，直到進程停止運行。

    3). 禁用大記憶體頁面：MongoDB需載入數量眾多小塊記憶體，所以啟用大頁面會導致更多的磁碟IO。

    4). 選擇一種磁碟調度演算法：磁碟控制卡從作業系統接收到請求後，會使用一種調度演算法來決定處理這些請求的順序。有時改變這一演算法可提高磁碟效能。

         在使用固態硬碟或者使用RAID控制器進行緩衝時，應使用noop調度演算法。

         可在啟動配置中使用--elevator選項來更改調度演算法。很多時候調度演算法都能很好的運作，差別不大。

    5). 不要記錄訪問時間：系統預設記錄檔案最後訪問時間。Mongod操作頻繁，禁用這一操作，會得到效能上的提升。在linux系統中，可以在/etc/fstab裡將atime更改為noatime，已禁止記錄訪問時間。

    6). 修改限制：MongoDB可能會受到兩個限制的影響：進程可建立線程的數量和進程能夠開啟檔案描述符(file descriptor)的數量。二者都應該被設定為無限制。

4. 網路設定

5. 系統管理: 

    1). 時鐘同步：一般來講，各系統的時鐘誤差不超過一秒最為安全。

    2). OOM Killer ： 如果MongoDB進程突然被終止，而日誌中又沒有出現錯誤或退出資訊，則應檢查/var/log/message(或核心記錄這些內容的其他位置，查看是否存在關於終止mongod進程的資訊。

         當系統沒有交換空間，並且可用記憶體開始減少時，OOM Killer就會變得尤為敏感，因此為了避免麻煩，不妨配置適當的交換空間。MongoDB應不會用到該交換空間，但這可讓OOM Killer放鬆下來。

         如果OOM killer終止了一個mongos進程，重啟它即可。

    3). 關閉定期任務：檢查是否存在計劃任務或後台進程，它們可能定期被啟用並消耗系統資源，比如軟體包管理器的自動更新。這些程式被啟用後會消耗大量的記憶體和CPU資源，然後又消失不見。我們不會

         希望在生產伺服器上見到這些東西。

 

設定交換空間的方法步驟：

1、建立swapfile：

root許可權下，建立swapfile，假設目前的目錄為"/",執行如下命令：

# dd  if=/dev/zero  of=swapfile  bs=1024  count=500000

則在根目錄下建立了一個swapfile,名稱為“swapfile”，大小為500M，也可以把檔案輸出到自己想要的任何目錄中，個人覺得還是直接放在根目錄下比較好，www.linuxidc.com一目瞭然，不容易誤破壞，放在其他目錄下則不然了；

命令中選項解釋：

---of：輸出的分頁檔的路徑及名稱；

---bs：塊大小，單位byte，一般為1k即1024個byte；

---count：總塊數即空間總大小，單位為塊即k；

---if：讀取的源空閑空間，為什麼是zero，不清楚，先固定這麼寫吧；

2、將swapfile設定為swap空間

# mkswap swapfile

3、啟用交換空間，這個操作有點類似於mount操作（個人理解）：

# swapon  swapfile

至此增加交換空間的操作結束了，可以使用free命令查看swap空間大小是否發生變化；

4、如果不再使用空間可以選擇關閉交換空間,這個操作有點類似於umount操作（個人理解）：:

#  swapoff  swapfile

使用這種方法在每次系統啟動時都需要手動設定、開啟swapfile，比較麻煩，解決方案：

在 /etc/rc.d/rc.local 檔案的末行下追加加以下內容：（編輯這個檔案當然是用vi了~）

/sbin/swapon  /swapfile

儲存後退出，這樣在系統啟動後，swap空間就會自動載入了；

總結：在安裝OS時一定要規劃後swap大小，通常為記憶體的2倍，但是要考慮到以後增加記憶體的可能，所以可以考慮設的稍大一些，不過在我們目前普遍使用的i386 PC機上，最大也不能超過2G。 

         

Mongodb 筆記09