MYSQL性能優化之Mysql資料庫高可用架構設計之MHA架構設計（下）

1. MHA（Master High Availability）是一個免費的開源工具,使用Prel開發。
2. MHA更多關注點是主從複制中的主DB.
3. 當主DB崩潰時，快速的在從伺服器中找到最佳伺服器。
4. 在MySQL故障切換過程中，MHA能做到在0~30秒之内自動完成資料庫的故障切換操作，并且在進行故障切換的過程中，MHA能在最大程度上保證資料的一緻性，以達到真正意義上的高可用。
5. 主伺服器當機時，MHA會嘗試從主伺服器盡可能多的儲存二進制日志，最大程度保證事務的不丢失。如果主伺服器硬體或者網絡出現問題（ssh無法通路），肯定也就無法儲存二進制日志了
6. MHA可以與半同步複制結合起來

MHA功能

MHA主從切換過程

- 2可以手動設定從伺服器不參與選舉

- 3彌補其他從伺服器資料差異

- 4如果重複的主鍵等會使MHA停止進行故障轉移

- 5虛拟IP切換

MHA提供兩個主要優點：

- 自動故障切換：有助于意外的主站故障，崩潰等等（故障切換也可以手動完成）。

- 快速線上主切換：在執行核心更新，MySQL更新，硬體更新等正常計劃或計劃維護操作時有用。

MHA示範架構（基于GTID）

MHA配置步驟

- SSH->故障轉移過程中儲存原主伺服器二進制日志，配置虛拟IP位址等

- 日志點和GTID（推薦）

- ssh和複制鍊路的監測

MHA執行個體

確定gtid在叢集中所有的伺服器中啟動

建立複制使用者

從資料庫初始化（略，備份，看上一篇）

從伺服器啟動複制鍊路

MHA配置

重複1，2步驟在每台伺服器執行一遍

生成密鑰之後，進行免密鑰密碼的配置

1 主伺服器生成ssh密鑰

2 主伺服器拷貝ssh密鑰到從伺服器（主伺服器的密鑰驗證也要配置）

3安裝包下載下傳

4 安裝prel支援包

資料節點隻需要這幾個包，每天伺服器都安裝

yum -y install perl-DBD-MYSQL nctfp perl-DBI.x86
           

每天伺服器都安裝node節點包

rpm -ivh mha.....rpm
           

監控伺服器安裝依賴（上面的那個指令（監控節點））

安裝監控包
rpm -ivh mha.....rpm
           

4 MHA配置（隻需要在監控伺服器配置就行）

• 建立配置檔案儲存目錄
• 建立mha工作目錄
• 建立配置檔案
  • 伺服器預設資訊
    • mha主從管理使用者（在主資料庫（節點1）建立）

    • 

    • 密碼
    • 管理服務工作目錄
    • remote_workdir遠端伺服器工作目錄（手動在每個伺服器建立）
    • ssh使用者（啟動mha時的使用者）
    • 複制使用者和密碼
    • ping_interval 檢查主資料庫是否可以連通的時間間隔
    • master_binlog_dir目錄
      • show variables like ‘%log%’; -> log_bin_basename（主伺服器檢視位置）
    • master_ip_failover_script執行腳本,完成主從切換之後，虛拟IP漂移
      • 還可以添加完成主從切換後，自動郵箱通知DBA
    • secondary_check_script(MHA預設隻通過monitor伺服器來監控主伺服器是否可用)，該腳本可以通過多網絡路徑來監測主伺服器是否可用（當網絡抖動時，避免錯誤切換）
  • 主機資訊
    • hostname
    • 參加master選舉的伺服器（不參加選舉）

腳本

5 監測MHA配置

檢視ssh免認證是否配置正确

監測主從複制的結構(環境)

6 啟動MHA

MHA不會自動的配置虛拟IP，是以需要手動配置

nohup(放到背景) masterha manager --conf=/etc/mha/mysql_mha.cnf & [1] 
ps -ef 
ifconfig eth0:1 192.168.3.90/24 配置虛拟IP
           

7 測試MHA

停止資料庫
/etc/init.d/mysql stop
ip addr 檢視虛拟IP是否轉移 OR
show slave status  監控伺服器
           

8 MHA優缺點

• 優點
  • Perl,開源
  • 支援GTID
  • MHA在故障轉移時不易産生資料丢失（加強資料安全性）
  • 同一個監控節點可以監控多個叢集
• 缺點
  • 沒有虛拟IP的配置
    • （腳本）->增加MHA工具複雜度
    • 第三方工具，失去自動從多個從伺服器去選取最優伺服器的功能，增加叢集部署的複雜性
      • MHA運作時不監控複制鍊路，也就無法發現問題（複制鍊路中斷，主從延遲增大）。
      • MMM在主從鍊路出現問題時，通過切換故障伺服器讀VIP方式來排除故障伺服器

      • 

讀寫分離

Mysql主從複制配置一個主要目的：為了分擔主庫的讀負載（讀>>寫）

那麼讀寫分離的目的：寫負載是不能分擔的，隻能在主上進行寫操作（讀操作，主從都可以）

兩種讀寫分離方式

• 由程式實作讀寫分離
  • 架構簡單，易于維護

  • 

  • DBA和開發（控制讀寫分離）之間溝通成本的增加（重上線，重新開機程式）

  • 

• 由中間件實作讀寫分離
  • mysql-proxy(實驗項目，一直沒正式上線) maxScale（MariaDB）
  • 依賴中間層的性能（損耗比較嚴重，最好上線前進行一些基準測試，QPS降低50%到70%）,故障點
  • 加入提示關鍵字，對程式修改->進而對程式不再透明

    

    

負載均衡

• 程式輪詢
• 軟體：LVS Haproxy MaxScale
• 硬體 ： F5

MaxScale Core

• Authentication
  • 認證連接配接：後端資料庫讀取Mysql.user->緩存到MS伺服器端->使用者連接配接->判斷是否通過驗證 ->無此使用者->對後端資料進行更新再進行驗證
• Protocal：負責MS和外部接口的協定
  • 用戶端到MS的接口（mysql用戶端協定插件）
  • MS到後端資料的接口（mysql服務端協定插件）
• Router
• readconnroute（多台伺服器負載均衡）
• readwritesplit（讀寫分離）
• Monitor 對後端資料庫進行實時監控(前端請求->正确的背景資料庫)
• Filter 資料庫防火牆（對sql過濾和改寫，sql容錯和自動轉換）

MaxScale Core安裝和配置

示範環境：一主兩從，主：192.168.3.101，從：192.168.3.100，192.168.3.102

賬号的建立（監控子產品，路由子產品 ）

加密密碼（略）

修改配置檔案

cd /etc/
ls -l maxscale*
           

• threads 程序（8）
• 伺服器資訊（全部）
• 監控子產品的配置（加密密碼填寫，略）
• 讀負載子產品（略）
• 讀寫分離子產品（也能實作讀負載）
  • 最大可用從伺服器數量（預設：all）
  • 從伺服器最大的延遲 （當延遲大于60s後，從伺服器不再參與讀寫分離）
• 監聽
  • 讀監聽
  • 讀寫子產品監聽（獨立伺服器，3306端口）

MaxScale Core啟動

maxscale --config=/etc/maxscale.cnf
确認
ps -ef | grep maxscale
netstat -ntelp
           

預設使用者admin，密碼：mariadb