標籤:.sh blog 網頁 核心 bin 中繼 允許 3.1 kernel
環境
OS: centos7
Mysql 版本: mysql 5.7
Keepalived: keepalived-1.2.20
Mysql-vip:192.168.41.100
Mysql-master1:192.168.41.10
Mysql-master2:192.168.41.11
實驗環境關閉防火牆規則firewall-cmd
一、配置兩台mysql互為主從
該過程的第一部分就是 master 記錄二進位日誌。在每個事務更新資料完成之前, master 在
二日誌記錄這些改變。MySQL 將事務寫入二進位日誌。在事件寫入二進位日誌完成後, master
通知儲存引擎提交事務。
下一步就是 slave 將 master 的 binary log 拷貝到它自己的中繼日誌。首先, slave 開始一個工
作線程——I/O 線程。I/O 線程在 master 上開啟一個普通的串連,然後開始 binlog dump process。
Binlog dump process 從 master 的二進位日誌中讀取事件,如果已經同步了 master,它會睡
眠並等待 master 產生新的事件。 I/O 線程將這些事件寫入中繼日誌。
SQL slave thread(SQL 從線程)處理該過程的最後一步。 SQL 線程從中繼日誌讀取事件,並
重放其中的事件而更新 slave 的資料,使其與 master 中的資料一致。 只要該線程與 I/O 線程
保持一致,中繼日誌通常會位於 OS 的緩衝中,所以中繼日誌的開銷很小。主主同步就是兩台機器互為主的關係,在任何一台機器上寫入都會同步。
1、修改mysql設定檔
兩台mysql均要開啟binlog日誌功能,兩台的server-id不能一樣:
master1配置如下:
[mysqld]
log-bin = mysql-bin
binlog_format = mixed
server-id = 1
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
auto-increment-increment = 2
auto-increment-offset = 1
重啟mysqld服務
systemctl restart mysqld
master2配置如下:
log-bin = mysql-bin
binlog_format = mixed
server-id = 2
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
auto-increment-increment = 2
auto-increment-offset = 2
重啟 mysqld 服務
systemctl restart mysqld
註: master1 和 master2 只有 server-id 不同和 auto-increment-offset 不同。
mysql 中有自增長欄位,在做資料庫的主主同步時需要設定自增長的兩個相關配置:
auto_increment_offset 和 auto_increment_increment。
auto-increment-increment 表示自增長欄位每次遞增的量,其預設值是 1。 它的值應設為整個
結構中伺服器的總數,本案例用到兩台伺服器,所以值設為 2。
auto-increment-offset 是用來設定資料庫中自動成長的起點(即初始值),因為這兩能伺服器都
設定了一次自動成長值 2,所以它們的起點必須得不同,這樣才能避免兩台伺服器資料同步
時出現主鍵衝突
2、將 master1 設為 master2 的主伺服器
在 master1 主機上建立授權賬戶,允許在 master2(192.168.41.11)主機上串連
在 master2 上將 master1 設為自已的主伺服器並開啟 slave 功能。
查看從的狀態, mysql>show slave status\G;以下兩個值必須為 yes,代表從伺服器能正常串連主
伺服器
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
3、 將 master2 設為 master1 的主伺服器
在 master2 主機上建立授權賬戶,允許在 master1(192.168.41.10)主機上串連
在 master1 上將 master2 設為自已的主伺服器並開啟 slave 功能。
show slave status\G 查看從的狀態,以下兩個值必須為 yes,代表從伺服器能正常串連主伺服器
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
4、測試主主同步
在 master1 上建立要同步的資料庫如 test_db,並在 test_db 中建立一張測試表如 tab1
查看 master2 主機是否同步了 master1 上的資料變化
在 master2 主機上向 tab1 表中插入資料
查看 master1 主機是否同步了 master2 上的資料變化
現在任何一台 MySQL 上更新資料都會同步到另一台 MySQL, MySQL 同步完成。
註: 若主 MYSQL 伺服器已經存在,只是後期才搭建從 MYSQL 伺服器,在置配資料同步前應
先將主 MYSQL 伺服器的要同步的資料庫拷貝到從 MYSQL 伺服器上(如先在主 MYSQL 上備
份資料庫,再用備份在從 MYSQL 伺服器上恢複)
下面我們就完成 keepalived 的高可用性。
keepalived 是叢集管理中保證叢集高可用的一個軟體解決方案,其功能類似於 heartbeat,用
來防止單點故障
keepalived 是以 VRRP 協議為實現基礎的, VRRP 全稱 Virtual Router Redundancy Protocol,即
虛擬路由冗餘協議。
虛擬路由冗餘協議,可以認為是實現路由器高可用的協議,即將 N 台提供相同功能的路由
器組成一個路由器組,這個組裡面有一個 master 和多個 backup, master 上面有一個對外提
供服務的 vip, master 會發組播(組播地址為 224.0.0.18),當 backup 收不到 vrrp 包時就認
為 master 宕掉了,這時就需要根據 VRRP 的優先順序來選舉一個 backup 當 master。這樣的話
就可以保證路由器的高可用了。
keepalived 主要有三個模組,分別是 core 、 check 和 vrrp。 core 模組為 keepalived 的核心,
負責主進程的啟動、維護以及全域設定檔的載入和解析。 check 負責健全狀態檢查,包括常見
的各種檢查方式。 vrrp 模組是來實現 VRRP 協議的。
二、 keepalived 的安裝配置
1、在 master1 和 master2 上安裝軟體包 keepalived
安裝 keepalived 軟體包與服務控制
在編譯安裝 Keepalived 之前,必須先安裝核心開發包 kernel-devel 以及 openssl-devel、
popt-devel 等支援庫。
編譯安裝 Keepalived
注意: 如不知道 keepalived 需要哪些依賴包,可到下載後的源碼解壓目錄下查看 INSTALL 文
件內容, +
注意:centos6 執行 make install 操作之後,會自動產生/etc/init.d/keepalived 指令檔,但還需要手動添加
為系統服務,這樣就可以使用 service、 chkconfig 工具來對 keepalived 服務程式進行管理了。
centos7:不要加----with-kernel-dircentos6加
./configure --prefix=/ --with-kernel-dir=/usr/src/kernels/3.10.0-327.el7.x86_64/ && make && make install
Master2 主機也完成 keepalived 安裝,與 master1 一樣,安裝過程略
2、 修改 Keepalived 的設定檔
keepalived 只有一個設定檔 keepalived.conf,裡面主要包括以下幾個配置地區,分別是
global_defs、 vrrp_instance 和 virtual_server。
global_defs: 主要是配置故障發生時的通知對象以及機器標識。
vrrp_instance: 用來定義對外提供服務的 VIP 地區及其相關屬性。
virtual_server:虛擬伺服器定義
master1 主機上的 keepalived.conf 檔案的修改:
vi /etc/keepalived/keepalived.conf:
! Configuration File for keepalived //!表示注釋global_defs {router_id MYSQL-1 //表示運行 keepalived 伺服器的一個標識}vrrp_instance VI_1 {state BACKUP //指定 keepalived 的角色, 兩台配置此處均是 BACKUP,設為 BACKUP 將根據優先順序決定主或從interface eth0 //指定 HA 監測網路的介面virtual_router_id 51 //虛擬路由辨別碼,這個標識是一個數字(取值在 0-255 之間,用來區分多個 instance 的 VRRP 組播),同一個 vrrp 執行個體使用唯一的標識,確保和 master2 相同,同網內不同叢集此項必須不同,否則發生衝突。priority 100 //用來選舉 master 的,要成為 master,該項取值範圍是 1-255(在此範圍之外會被識別成預設值 100) ,此處 master2 上設定為 50advert_int 1 //發 VRRP 包的時間間隔,即多久進行一次 master 選舉(可以認為是健康查檢時間間隔)nopreempt //不搶佔, 即允許一個 priority 比較低的節點作為 master,即使有 priority更高的節點啟動authentication { //認證地區,認證類型有 PASS 和 HA(IPSEC),推薦使用 PASS(密碼只識別前 8 位)auth_type PASSauth_pass 1111}virtual_ipaddress { //VIP 地區,指定 vip 地址192.168.1.100}}virtual_server 192.168.1.100 3306 { //設定虛擬伺服器,需要指定虛擬 IP 位址和服務連接埠, IP 與連接埠之間用空格隔開delay_loop 2 //設定運行情況檢查時間,單位是秒lb_algo rr //設定後端調度演算法,這裡設定為 rr,即輪詢演算法lb_kind DR //設定 LVS 實現負載平衡的機制,有 NAT、 TUN、 DR 三個模式可選persistence_timeout 60 //會話保持時間,單位是秒。這個選項對動態網頁是非常有用的,為叢集系統中的 session 共用提供了一個很好的解決方案。 有了這個會話保持功能,使用者的請求會被一直分發到某個服務節點,直到超過這個會話的保持時間。protocol TCP //指定轉寄協議類型,有 TCP 和 UDP 兩種real_server 192.168.1.101 3306 { //佈建服務節點 1,需要指定 real server 的真實 IP 位址和連接埠, IP 與連接埠之間用空格隔開註: master 2 上此處改為 192.168.1.102(即 master2 本機 ip)weight 3 //佈建服務節點的權值,權值大小用數字表示,數字越大,權值越高,設定權值大小為了區分不同效能的伺服器notify_down /etc/keepalived/bin/mysql.sh //檢測到 realserver 的 mysql 服務 down後執行的指令碼TCP_CHECK {connect_timeout 3 //連線逾時時間nb_get_retry 3 //重連次數delay_before_retry 3 //重連間隔時間connect_port 3306 //健全狀態檢查連接埠}}}
master1 主機上有關 keepalived.conf 檔案的具體配置如下:
啟動keepalived
systemctl start keepalived.service
ps -aux |grep keep
Master2 主機上的 keepalived.conf 檔案的修改:
啟動keepalived服務
systemctl start keepalived.service
3、 #mkdir /etc/keepalived/bin
vi /etc/keepalived /bin/mysql.sh,內容如下:
Master2 主機完成相同的操作
4、測試
在 master1 和 master2 分別執行 ip addr show dev eth0 命令查看 master1 和 master2 對 VIP
(群集虛擬 IP)的控制權。
Master1 主的查看結果:
Master2 主的查看結果:
從可以看出 master1 是主伺服器, master2 為待命伺服器。
停止 MySQL 服務,看 keepaliv ed 健全狀態檢查程式是否會觸發我們編寫的指令碼
停止 master1 主機的 mysql 服務
Master2 主的查看結果:
這說明在主服務上停止 MySQL 服務,觸發了我們編寫的指令碼,進行自動故障切換。
MySQL 遠程登入測試
我們找一台安裝有 MySQL 用戶端,然後登入 VIP,看是否能登入,在登入之前兩台 MySQL
伺服器都要授權允許從遠程登入。例如:
grant all on . to [email protected]‘%‘ identified by ‘123456‘;
在用戶端上測試登入(把幹才關閉master1啟動):
顯示說明在用戶端訪問 VIP 位址,由 master1 主機提供響應的,因為 master1 當前是主
伺服器, 將 master1 的 mysql 服務停止, 在用戶端執行 show variables like ‘server_id’;
顯示說明在用戶端的查詢請求是由 master2 主機響應的。故障切換成功。
總結:
Keepalived+mysql 雙主一般來說,中小型規模的時候,採用這種架構是最省事的。
在 master 節點發生故障後,利用 keepalived 的高可用機制實現快速切換到備用節點。
在這個方案裡,有幾個需要注意的地方:
1.採用 keepalived 作為高可用方案時,兩個節點最好都設定成 BACKUP 模式,避免因為意外
情況下(比如腦裂)相互搶佔導致往兩個節點寫入相同資料而引發衝突;
2.把兩個節點的 auto_increment_increment(自增步長)和 auto_increment_offset(自增起
始值)設成不同值。其目的是為了避免 master 節點意外宕機時,可能會有部分 binlog 未能
及時複製到 slave 上被應用,從而會導致 slave 新寫入資料的自增值和原先 master 上衝突了,
因此一開始就使其錯開;當然了,如果有合適的容錯機制能解決主從自增 ID 衝突的話,也
可以不這麼做;
3.slave 節點伺服器配置不要太差,否則更容易導致複寫延遲。作為熱備節點的 slave 伺服器,
硬體設定不能低於 master 節點;
4.如果對延遲問題很敏感的話,可考慮使用 MariaDB 分支版本,或者直接上線 MySQL 5.7 最
新版本,利用多線程複製的方式可以很大程度降低複寫延遲;
mysql雙主+keepalived