MySQL 磁碟複製技術–DRBD：優缺點比較、注意事項以及最佳實務

    DRBD 是核心模組方式實現的塊層級同步複製技術、這裡的同步層級是可以調整的
   因為DRBD 是利用網卡進行塊複製、如果、這裡用 Infiniband 進行傳輸、便可以有效處理高並發
   這是種複製儲存、說白點、更像是一台熱備機器、與其說是儲存的HA、倒不如說是保證資料安全
   工業環境更多用在 NFS 伺服器、並結合 Linux-HA 項目、如 Packmaker、Heartbeat 等
   
   
   很多人談 DRBD 腦裂而色變、用過就知道了、腦裂不是那麼容易就發生的
   DRBD 注意不設定自動啟動、重啟時候手動啟動、腦裂的情況發生非常的少
   工作中基本不重啟 DRBD、更不會重啟伺服器了、基本上沒遇到腦裂的問題
   
   
   
    ㈠ 優缺點比較
   
   
    優點
   
   ① 沒有單點故障的風險暴露
   ② 沒有叢集軟體通病、如 腦裂
   
   
    缺點
   
    ⑴ 浪費資源
      
      DRBD 的備機目前還不能提供讀、所以浪費了資源
      大家都知道、生產環境下的 MySQL 伺服器都是頂配的、這樣線上上浪費一台機器、感覺很可惜的
      
    ⑵ DRBD 無法代替備份
      
      DRBD 可能會造成壞資料、不管啥HA、資料備份一定要有、沒備份、整個HA癱瘓掉、你也嗝屁了、閃人吧
      
    ⑶ 容錯移轉無法做到秒級以內
   
    ⑷ 對於MyISAM 表用處不大
      
      事實上、任何期望高可用的系統、MyISAM 都不會是個選擇、因為
      MyISAM 的崩潰恢複後需要很多時間修複、並且、會遺失資料
      
    ⑸ 增加寫操作負擔
      
      主要是InnoDB 設定為 innodb_flush_log_at_trx_commit=1
      導致許多小的寫入和fsync()調用、那麼、DRBD同步將會比較緩慢
   
   
   
    ㈡ 注意事項
      
      
      ① DRBD 和 Linux-HA 版本選擇
      ② DRBD 專門使用一塊網卡
      ③ 心跳網路與vip服務網路分離
      ④ iptables針對心跳網路放開DRBD、Linux-HA 的連接埠、VIP可根據自己的應用開啟對應連接埠
      ⑤ 監控DRBD、Linux-HA 狀態、最好做成指令碼、自動檢測、出問題警示
      ⑥ 通常都有流量監控系統（mrtg,cacti等）、定期檢查機器的負載、流量情況
      
   
   
    ㈢ 最佳實務
      
      DRBD 只選擇複製存放 binlog 的裝置、如果、
      主動節點失效、可以在被動節點上開啟一個Log Service器
      然後、對失效主庫的所有裝置應用這些 binlog 、接下來
      可以選擇其中一個備庫提升為主庫、以代替失效的系統
      
      
      
   就這樣了、over 、欲知詳情、參見官網：drbd.org 
   
   
   By David lin
   2013-05-31 
   Good Luck