MySQL之容災方案解讀

更新時間：2023年03月13日 09:21:44 作者：Demonson

這篇文章主要介紹了MySQL之容災方案，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教

MySQL容災方案

容災方案

目前有以下三種容災方案可供參考：

1.主從半同步復制+手動切換

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

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

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

2.主從半同步復制+keepalived自動切換

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

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

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

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

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

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

缺點：費用較高

MySQL異地備份策略容災腳本--shell

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

[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" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?--------------異地的目標存放全備路徑
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