MySQL容災(zāi)方案

容災(zāi)方案

目前有以下三種容災(zāi)方案可供參考：

1.主從半同步復(fù)制+手動切換

方案介紹：由兩臺服務(wù)器上的數(shù)據(jù)庫實例搭建主從架構(gòu)，兩個實例之間的數(shù)據(jù)同步使用MySQL半同步復(fù)制機(jī)制。主機(jī)綁定VIP，在主庫故障后手動將VIP綁定至備機(jī)，將上層請求切換至備庫，備庫寫入數(shù)據(jù)后成為新主，原主實例恢復(fù)后成為新主的備庫，具體架構(gòu)圖如下：

優(yōu)點：不存在VIP漂移問題，規(guī)避因底層同步延時導(dǎo)致的數(shù)據(jù)不一致。

缺點：故障時需要人工介入，效率低。

2.主從半同步復(fù)制+keepalived自動切換

方案介紹：由兩臺服務(wù)器上的數(shù)據(jù)庫實例搭建主從架構(gòu)，VIP綁定在主實例上，程序通過VIP將數(shù)據(jù)寫入主庫。主實例由keepalived中間件通過腳本判活，如果檢測失敗則停止主機(jī)keepalived服務(wù)，VIP漂至從機(jī)，程序數(shù)據(jù)繼續(xù)入庫，具體架構(gòu)圖如下：

優(yōu)點：實現(xiàn)故障自動切換，無需人工干預(yù)

缺點：如存在網(wǎng)絡(luò)閃斷等情況影響存活判斷，可能會導(dǎo)致主從多次切換，造成潛在數(shù)據(jù)不一致問題

阿里云MySQL RDS使用的高可用方案如下圖所示，兩臺數(shù)據(jù)庫實例組成主從模式，正常情況下應(yīng)用層通過SLB訪問主庫，從庫不可訪問；主庫故障則SLB自動切換至連接從庫，上層應(yīng)用無感知。

同時也支持手動模式進(jìn)行實例切換，具體架構(gòu)圖如下：

優(yōu)點：數(shù)據(jù)庫托管給云平臺，降低運維成本

缺點：費用較高

MySQL異地備份策略容災(zāi)腳本--shell

由于公司的機(jī)器異地的是win主機(jī)，需要把linux的備份腳本遠(yuǎn)程傳輸?shù)竭@臺win上，所以我選擇ftp，大家可以使用wput會好很多，而且比較強(qiáng)大；

[root@Mysql28 shell]# cat test.sh?
#!/bin/bash
#tar xvzfi --------commond
backupdir=/data/back_up/mysql
ip_d=192.168.155.139
full_d=cctalk_full
date_d=$(date "+%Y%m%d%H%M%S")
DataBakName=$ip_d.$date_d.$full_d.tar.gz ? ? ? ? ? ? ? ? ? ? ? ? ?--------------全備下來后的名稱策略，例如；192.168.155.139.20131126134602.cctalk_full.tar.gz
ftp_backup="D:\\dbbackup\\fullbackup" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?--------------異地的目標(biāo)存放全備路徑
mkdir -p $backupdir
find $backupdir -mtime +10 -type d ?-exec rm -rf {} \; ? ? ? ? ? ? ? ? ------------剔除保留10天以外的全備腳本；
innobackupex ?--user=root ?--password="root" --databases="test" ?--parallel=12 ?--no-lock --defaults-file=/etc/my.cnf --stream=tar ?/data/back_up/mysql/ ?2>/tmp/mysqlbackup.log|gzip -1 - >/data/back_up/mysql/$DataBakName ? ? ?--------innobackup的全備腳本，以及壓縮，gzip -1比較快，大家可以用-9壓縮的效率高，不過比較慢
ftp -v -n 192.168.25.163 << END ? ? ---ftp,同樣可以使用wput來更快更方便的傳輸！
user ftpuser xxxxxxx ? ? ? -----------------fpt的賬號和密碼！
type binary
cd fullbackup
lcd $backupdir
put $DataBakName
bye
END

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論