MariaDB基於MHA和Galera Cluster實現高可用
阿新 • • 發佈：2019-05-11
只有一個 不可 點數據 percona 半同步復制 監控 完整性 自己 mode MySQL高可用
-
MMM：MySQL主主復制管理器是一套靈活的腳本程序，基於perl實現，用來對mysqk replication進行監控和故障遷移，並能管理mysql master-master復制的配置（同一時間只有一個節點是可寫的）
-
MHA：對主節點進行監控，可實現自動故障轉移至其他從節點，通過提升某一節點為新的主節點，基於主從復制實現，還需要客戶端配合時間，目前MHA主要支持一主多從的架構，要搭建MHA，要求一個復制集群匯總最少有三臺數據庫服務器，一主二從，即一太充當master，一臺充當備用master，另外一臺充當從庫，由於機器成本的考慮，阿裏巴巴對其進行了改造，目前TMHA已支持一主一從
-
Galera Cluster：wsrep(MySQL extended with the Write Set Replication)，通過wsrep協議在全局實現復制，在任何一節點可讀寫，不需要主從復制，實現多主寫
- GR：MySQL官方提供的組復制技術（MySQL 5.7.17引入的技術），基於原生復制技術Paxos算法
MHA的工作原理：
- 從宕機崩潰的master保存二進制日誌事件（binlog event）
- 識別含有最新的更新的slave
- 應用差異的中繼日誌（relay log）到其他的slave
- 應用從master保存的二進制日誌事件
- 提升一個slave為新的master
- 使其他的slave連接新的master進行復制
MHA軟件包的兩個組成部分：
- Manager工具包： masterha_check_ssh 檢查MHA的ssh配置情況 masterha_check_repl 檢查MySQL復制狀況 masterha_manager 啟動MHA masterha_check_status 檢測當前MHA運行狀態 masterha_master_monitor 檢測master是否宕機 masterha_master_switch 故障轉移（自動或手動） masterha_conf_host 添加或刪除配置的server信息 - Node工具包： save_biary_logs 保存和復制master的二進制日誌 apply_diff_relay_logs 去除不必要的rollback時間（MHA已不再使用） purge_relay_logs 清除中繼日誌（不會阻塞SQL線程）
註：
- 這些工具通常是由MHA Manager的腳本觸發，無需人為操作
- 為了盡可能的減少主庫硬件損壞宕機造成數據丟失，因此在此配置的MHA的同時建議配置成MySQL5.5的半同步復制
- 自定義擴展：
secondary_check_script 通過多條網絡路由檢測master的可用性
mater_ip_ailover_script 更新application使用的master ip
shutdown_script 強制關閉master節點
report_script 發送報告
init_conf_load_script 加載初始化配置參數
master_ip_online_change_script 更新master節點ip地址配置文件：
global配置：為各個application提供默認配置
application配置：為每個主從復制集群提供默認配置軟件包：
- 管理節點的軟件包：
mha4mysql-manager
mha4mysql-node - 在被管理節點安裝：
mha4mysql-node註：
1.管理節點與主從節點要實現ssh基於key驗證
2.所有節點的時間要同步
實現MHA：
-
在所有節點實現相互之間ssh key驗證
- 在管理節點建立配置文件：
vim /etc/mastermha/app1.cnf [server default] #MAH節點配置 user=mhauser #管理主從節點的賬號 password=admin123 manager_workdir=/data/mastermha/app1/ manager_log=/data/mastermha/app1/manager.log remote_workdir=/data/mastermha/app1/ ssh_user=root #通過ssh協議連接的用戶 repl_user=repluser #主從同步的用戶 repl_password=admin123 ping_interval=1 #檢測master節點正常與否的頻率 [server1] hostname=172.22.45.131 #master節點 candidate_master=1 [server2] hostname=172.22.45.132 #master節點故障後，默認將此從節點提升為master candidate_master=1 [server3] hostname=172.22.45.133 -
主節點配置：
[mysqld] log-bin server_id=1 skip_name_resolve=131 mysql>show master logs mysql>grant replication slave on *.* to [email protected]‘172.22.45.131.%‘ identified by ‘admin123‘; mysql>grant all on *.* to [email protected]‘172.22.45.131.%‘ identified by ‘admin123‘; -
從節點1：
vim /etc/my.cnf [mysqld] server_id=132 log-bin read_only relay_log_purge=0 skip_name_resolve=1 mysql>CHANGE MASTER TO MASTER_HOST=‘172.22.45.131‘,MASTER_USER=‘repluser‘, MASTER_PASSWORD=‘admin123‘,MASTER_LOG_FILE=‘mariadb-bin.000001‘, MASTER_LOG_POS=245; -
從節點2：
vim /etc/my.cnf [mysqld] server_id=133 log-bin read_only relay_log_purge=0 skip_name_resolve=1 mysql>CHANGE MASTER TO MASTER_HOST=‘172.22.45.131‘,MASTER_USER=‘repluser‘, MASTER_PASSWORD=‘admin123‘,MASTER_LOG_FILE=‘mariadb-bin.000001‘, MASTER_LOG_POS=245; - 驗證啟動：
- Mha節點驗證和啟動
masterha_check_ssh --conf=/etc/mastermha/app1.cnf # 驗證ssh基於key驗證是否正確 masterha_check_repl --conf=/etc/mastermha/app1.cnf # 驗證主從服務器同步是否正確 masterha_manager --conf=/etc/mastermha/app1.cnf - 排錯日誌： /data/mastermha/app1/manager.log
- Mha節點驗證和啟動
-
測試：
殺掉mysql master主進程後看到MHA管理端退出並報告：
MySQL Master failover 172.22.45.131(172.22.45.131:3306) to 172.22.45.132(172.22.45.132:3306)- 將master從172.22.45.131遷移為172.22.45.132
- 同時將172.22.45.132的read_only的值改為0：
select @@read_only; +-------------+ | @@read_only | +-------------+ | 0 | +-------------+ - 將172.22.45.133的主從復制的主服務器指向改為172.22.45.132
Galera Cluster:
繼承了Galera插件的MySQL集群，是一種新型的，數據不共享的，高度冗余的高可用方案，目前目前Galera Cluster有兩個版本，分別是Percona Xtradb Cluster及MariaDB Cluster，Galera本身是具有多主特性的，即采用multi-master的集群架構，是一個既穩健，又在數據一致性、完整性及高性能方面有出色表現的高可用解決方案
如：三個節點組成了一個集群，與普通的主從架構不同，它們都可以作為主節點，三個節點是對等的，稱為multi-master架構，當有客戶端要寫入或者讀取數據時，連接哪個實例都是一樣的，讀到的數據是相同的，寫入某一個節點之後，集群自己會將新數據同步到其它節點上面，這種架構不共享任何數據，是一種高冗余架構-
特點：
- 多主架構：真正的多點讀寫的集群，在任何時候讀寫數據，都是罪行的
- 同步復制：集群不同節點之間的數據同步，沒有延遲在數據庫掛掉之後，數據不會丟失
- 並發復制：從節點APPLY數據時，支持並行執行，更好的性能
- 故障切換：在出現數據庫故障時，因支持多點寫入，切換容易
- 熱插拔：在服務期間，如果數據庫掛了，只要監控程序發現的夠快，不可服務時間就會非常少。在節點故障期間，節點本身對集群的影響非常小
- 自動節點克隆：在新增節點，或者停機維護時，增量數據或者基礎數據不需要人工手動備份提供，Galera Cluster會自動拉取在線節點數據，最終集群會變為一致
- 對應用透明：集群的維護，對應用程序是透明的
- Galera Cluster包括兩個組件：
- Galera replication library (galera-3)
- WSREP：MySQL extended with the Write Set Replication
- WSREP復制實現：
- PXC：Percona XtraDB Cluster，是Percona對Galera的實現
- MariaDB Galera Cluster
- 參考倉庫：https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.64/yum/centos7-amd64/
註意：都至少需要三個節點，不能安裝mariadb-server
- 參考倉庫：https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.64/yum/centos7-amd64/
安裝部署：
- 創建yum源並安裝：
vim /etc/yum.repos.d/ganlera.repo [galera] baseurl=https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.64/yum/centos7-amd64/ gpgcheck=0 yum install MariaDB-Galera-server -
更改配置文件：
vim /etc/my.cnf.d/server.cnf [galera] wsrep_provider = /usr/lib64/galera/libgalera_smm.so #模塊文件路徑 wsrep_cluster_address="gcomm://172.22.45.131,172.22.45.132,172.22.45.133" #集群節點 binlog_format=row #二進制日誌記錄格式 default_storage_engine=InnoDB #存儲引擎 innodb_autoinc_lock_mode=2 bind-address=0.0.0.0 #下面配置可選項 wsrep_cluster_name = ‘mycluster‘#集群名默認my_wsrep_cluster wsrep_node_name = ‘node1‘ #每個節點的名字 wsrep_node_address =‘172.22.45.134‘ - 啟動
首次啟動時，需要初始化集群，在其中一個節點上執行命令
- service mysql start --wsrep-new-cluster：開啟一個新的集群節點
- 而後正常啟動其它節點
service mysql start - 查看集群中相關系統變量和狀態變量
SHOW VARIABLES LIKE ‘wsrep%‘;
SHOW STATUS LIKE ‘wsrep%‘;
SHOW STATUS LIKE ‘wsrep_cluster_size‘; 查看集群節點個數
MariaDB基於MHA和Galera Cluster實現高可用