基於keepalived配置數據庫主從實現高可用

基於keepalived配置數據庫主從實現高可用

使用keepalived來監聽端口,實現數據庫的高可用。實現效果,其中一臺數據庫服務器突然出故障或關機時,應該不影響應用正常運行,等待服務器啓動之後,數據能夠自動同步,保持數據一致性。

主從配置

架構圖及原理

  1. 主從狀態下,必須保證業務數據實際寫入Master數據庫,Slave數據庫只承擔讀的作用;
  2. Master 數據庫只要發生變化,立馬記錄到Binary log日誌文件中;
  3. Slave數據庫啓動一個I/O thread連接Master數據庫,請求Master變化的二進制日誌;
  4. Slave I/O獲取到的二進制日誌,保存到自己的Relay log 日誌文件中;
  5. Slave 有一個 SQL thread定時檢查Realy log是否變化,變化那麼就更新數據。

數據庫資源

數據庫 數據庫IP 節點
Gbase1 192.168.0.52 Master
Gbase2 192.168.0.53 Slave

配置步驟

主master配置

  1. 修改配置文件,添加以下內容(gs.cnf)
server-id=1
log-bin=gbase-log #開啓binlog日誌
binlog_fromat=row

重啓數據庫 2. 重啓數據庫並登陸數據庫 #創建同步用的賬號

set SQL_LOG_BIN=0;
CREATE USER 'save'@'%' IDENTIFIED WITH gbase_native_password BY '123456';
#添加權限
grant replication slave on *.* to 'save'@'%' ;
#刷新權限(使立即生效)
flush privileges;
set SQL_LOG_BIN=1;
3、獲取binlog文件名和POS

SHOW MASTER STATUS;

配置從slave庫

  1. 修改配置文件,添加以下內容(gs.cnf)
server-id=2
log-bin=gbase-log   #開啓binlog日誌
binlog_fromat=row # 設置binlog日誌格式

重啓數據庫 2. 登陸數據庫,根據主master庫的binlog文件名和POS進行同步配置

#先停止同步
stop slave;
#同步信息配置
CHANGE MASTER TO
MASTER_HOST='192.168.1.101',
MASTER_USER='save',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='bin-log.000003',
MASTER_LOG_POS=817;
#啓動slave同步
start slave;
#查看同步狀態

show slave status\G;

基於keepalived實現高可用

  1. 下載安裝包
  2. 解壓到指定目錄 tar -zxvf keepalived-1.2.2.tar.gz
  3. 執行安裝檢測
./configure --prefix=/usr/local/keepalived

錯誤代碼

configure: error:
   OpenSSL is not properly installed on your system. !!!
   Can not include OpenSSL headers files.   

解決方法

正常如果能夠連網絡執行一下命令即可,但是由於是內網,通過yum直接安裝缺少的包是安裝不了的

yum install -y openssl openssl-devel

所以這種環境下只能通過下載離線的相關包。下載地址如下,這個網站rpm包比較齊全,可以收藏一下

[[linux內核相關包下載]

分別下載並安裝:

keepalived-1.3.5-1.ns7_4.mips64el.rpm
net-snmp-5.7.2-28.ns7_4.2.mips64el.rpm
net-snmp-agent-libs-5.7.2-28.ns7_4.2.mips64el.rpm
net-snmp-libs-5.7.2-28.ns7_4.2.mips64el.rpm
openssl-1.0.2k-12.ns7_4.2.mips64el.rpm
openssl-devel-1.0.2k-12.ns7_4.2.mips64el.rpm
openssl-libs-1.0.2k-12.ns7_4.2.mips64el.rpm
 rpm -ivh example.rpm

配置keepalived

實現原理,主從服務器都設置同一個虛擬ip,如果兩臺服務器都開啓了了數據庫服務,則會根據keepalived的priority設置的優先級跳轉到優先級高的服務器,keepalived服務通過監聽數據庫端口,如果監聽發現該端口已經關閉,則需要關閉keepalived服務,此時ip自動漂移到備用服務器。

keepalived 相關操作

systemctl start keepalived #啓動服務
systemctl stop keepalived #停止服務
systemctl status keepalived # 查看keepalived狀態
systemctl restart keepalived # 重啓服務

修改默認keepalived.conf

vim /etc/keepalived/keepalived.conf

vrrp_script check_port {#創建一個vrrp_script腳本,檢查配置
    script "/etc/keepalived/check_port.sh 5258" #配置監聽的端口
    interval 3 #檢查腳本的頻率,單位(秒)
}
vrrp_instance VI_1 {
   state MASTER  #配置爲BACKUP節點,一般有三個配置可選MASTER(主機)、BACKUP(備機)
   interface ens33 #ifconfig確定
   virtual_router_id 51 #路由器標識,MASTER和BACKUP必須是一致的
   priority 100 #定義優先級,數字越大,優先級越高,在同一個vrrp_instance下,MASTER的優先級必須大於BACKUP的優先級。這樣MASTER故障恢復後,就可以將VIP資源再次搶回來
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass 123456
   }
   virtual_ipaddress {
       192.168.11.25 # 虛擬ip
   }
   track_script {
	check_port #執行指定vrrp_script腳本
    }
}

check_port.sh腳本

#!/bin/bash
#keepalived 監控端口腳本
CHK_PORT=$1
echo $CHK_PORT
if [ "$CHK_PORT" != "" ];then

	PORT_PROCESS=`lsof -i:$CHK_PORT|grep LISTEN|wc -l`
	if [ $PORT_PROCESS -eq 0 ];then
	echo "Port $CHK_PORT Is Not Used,End."
	
	sleep 2
		PORT_PROCESS=`lsof -i:$CHK_PORT|grep LISTEN|wc -l`
		if [ $PORT_PROCESS -eq 0 ];then
		#停止keepalived服務
		systemctl stop keepalived.service
		fi
	fi
else
	echo "Check Port Cant Be Empty!"
fi

驗證結果

  1. 首先啓動兩臺服務器的數據庫、keepalived服務。
  2. 連接指定虛擬 ip 訪問數據庫,此時應該先跳轉到優先級高的 master 服務器。
  3. 此時關閉優先級高的數據庫服務器,通過虛擬ip訪問數據庫,此時應該跳轉到 Slave 服務器。
  4. 再次開啓主數據庫服務器,通過虛擬 ip 訪問數據庫,此時再次跳轉到 master 服務器。

配置過程中遇到的問題及解決方法

shell腳本一直不行

執行shell腳本一直運行不了,提示結束符錯誤,後面將裏面內容只保留了幾行,還是有錯,

解決2

最後解決辦法,將腳本內容copy,然後新建一個腳本。才能夠正常執行。 原因:由於開始的腳本是從windows機器拷貝進去的,可能由於中間編碼存在一些問題,所以一直報錯。

keepalived監聽腳本一直執行不了

解決方法

  1. 需要確定該腳本能夠正常執行,所以需要手動執行一下看腳本是否有錯。
  2. 查看系統tail -f /var/log/messages 監控主機日誌。 /etc/keepalived/check_port.sh exited due to signal 15 3.vrrp_script{}中的interval時間需大於腳本中的sleep時間,開始兩個時間設置成一樣大小了。

數據庫突然主從同步不了

show slave status /G; 查看slave狀態

Slave_IO_Running: Yes
Slave_SQL_Running: No
而且出現了1062錯誤,還提示
Last_SQL_Error: Error 'Duplicate entry '1020202' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into testtable (id,mid,pid) values (1020202,1001,0)'

很顯然,由於主庫重啓導致 從庫數據不同步而且主鍵衝突。查看error 日誌發現error日誌文件變得好大,比以前大了將近好幾倍, tail -f gbase_error.log 最開始查看到的是這條信息。 此時由於我在測試時兩邊數據不一致導致。後面用新建的一個庫來測試正常。 如查出現錯誤,會導造主從複製破壞,此時將不能同步數據,需要手工處理,把兩邊數據保持一致後,再重新設置同步節點。並針對於一些錯誤代碼,可以選中跳過,否則主從同步容易停止。 修改gs.cnf slave-skip-errors = 1062 (忽略所有的1062錯誤) 並需要對從庫進行數據恢復,保持主從數據庫一致性。

總結

這一次設置的主從數據庫是用的國產數據庫gbase的,但是他是基於mysql的,所以主從的原來和mysql是一模一樣的。我們只要掌握了mysql的基礎,就能夠用同樣的方式配置出來gbase的主從。操作數據庫時一定要注意備份。慎用rm -rf /xxx 命令。不然真的要刪庫跑路了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章