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實現高可用