MySQL數(shù)據庫高可用HA實現(xiàn)小結
MySQL數(shù)據庫高可用HA實現(xiàn)
1、 數(shù)據庫高可用分析
高可用的衡量標準
數(shù)據庫實現(xiàn)高可用的幾種?式
MySQL數(shù)據庫實現(xiàn)高可用
2、MySQL主從復制的容災處理
MySQL支持的復制方式分析
主從場景切換方式
主從結構如何實現(xiàn)容災
1. 什么是數(shù)據庫高可用
1.1. 什么是高可用集群
N+1:N就是集群,1就是高可用,?可?的核?就是冗余,集群是保證服務最低使用標準的
1.2. 高可用集群的衡量標準
一般是通過系統(tǒng)的可靠性和可維護性來衡量的
MTTF:平均無故障時間,這是衡量可靠性的
MTTR:衡量系統(tǒng)的可維護性的
HA=MTTF/(MTTF+MTTR)*100%
SLA:99.999%:表示?年故障時間/宕機時間不超過6分鐘
1.3. 實現(xiàn)高可用的三種方式
主從方式(?對稱)
這種?式的組織形式通常都是通過兩個節(jié)點和?個或多個服務器,其中?臺作為主節(jié)點
(active),另?臺作為備份節(jié)點(standy),備份節(jié)點應該隨時都在檢測主節(jié)點的健康狀況,當
主節(jié)點發(fā)?故障,服務會?動切換到備份節(jié)點保障服務正常運?
對稱?式
兩個節(jié)點,都運?著不同的服務且相互備份,相互檢測對?的健康,當任意?個節(jié)點發(fā)?故障,這
個節(jié)點上的服務就會?動切換到另?節(jié)點
多機方式
包含多個節(jié)點多個服務,每個節(jié)點都要備份運?不同的服務,出現(xiàn)問題?動遷移
1.4. MySQL數(shù)據的高可用實現(xiàn)
1.4.1. 主從方式(?對稱)
資源:兩臺同版本的MySQL數(shù)據庫
主從實現(xiàn)的內部運行原理和機制
First Step:主數(shù)據庫服務器會把數(shù)據的修改記錄記錄進binlog?志,binlog?定要打開
Second Step:從庫的I/O進行讀取主庫的binlog內容后存???的Relay Log中繼?志中,這
個I/O線程會和主庫建??個普通的客戶端連接,然后主庫啟動?個?進制轉儲線程,I/O線
程通過轉儲線程讀取binlog更新事件,同步完畢后I/O進?sleep,有新的更新會再喚醒
Relay Log和Binlog的格式是?樣的,可以?mysqlbinlog讀取,也可show
mysql> show relaylog events in 'relay-log.000001';
?前數(shù)據庫有兩種復制?式
binlog?志點position
GTID?式也要依賴binlog
第三步:從服務器的SQL進程會從Relay Log中讀取事件并在從庫中重放
從服務器執(zhí)?重放操作時是可以在配置?聲明是否寫?服務器的binlog?志中
1.4.2. 配置主從服務步驟
1.4.2.1. Binlog的?志點?式配置主從同步
配置主從服務器參數(shù)
在Master服務器上創(chuàng)建?于復制并授權的數(shù)據庫賬號
備份Master數(shù)據庫并初始化Slave服務器數(shù)據
啟動復制鏈路
Master服務器配置
chown -R mysql:mysql /usr/local/binlog/ #配置?件 server_id=163 log_bin=/usr/local/binlog/mysql-bin 12345
Slave服務器配置
server_id=196 log_bin=/usr/local/binlog/mysql-bin relay_log=/usr/local/relaylog/relay-bin #當slave宕機后,如果relay log損壞了,導致?部分中繼?志沒有處理,則放棄所有未完成的, 重新獲取執(zhí)行,保證完整性 relay_log_recovery=1 #讓從庫數(shù)據只讀,super用戶,super_read_only=on read_only=on #從庫的復制鏈路服務不會隨數(shù)據庫重啟而重啟,需要手動啟動 skip_slave_start=on #確保數(shù)據?致性,通過innoDB的崩潰恢復機制來保護哦 master_info_repository=TABLE relay_log_info_repository=TABLE #select * from mysql.slave_master_info; #select * from mysql.slave_relay_log_info;
主庫授權
mysql> use msyql; mysql> grant replication slave on *.* to 'syncuser'@'192.168.0.103' identified by '123456'; mysql> flush privileges; set global validate_password_policy=LOW; set global validate_password_length=6;
初始化數(shù)據
mysqldump -uroot -p123456 --master-data=2 --single-transaction --routines - -triggers --events --databases mydb > mydb.sql
創(chuàng)建復制鏈路
mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.102', MASTER_PORT=3306, MASTER_USER='syncuser', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=8122; mysql> start slave; mysql> show slave status \G;
從庫的binlog是否寫??
默認情況下是不寫入的:因為寫入binlog會消耗I/O,所以性能會下降,如果需要在從庫上恢復數(shù)
據就到Relay Log里進?導出處理
直接在從庫上操作更?語句則會寫入binlog
如果就是需要寫入?在從庫的my.cnf : log_slave_updates=on #開啟同步并寫入binlog
開啟同步并寫入binlog應用于從到從的情況
問題:只同步其中三個表
#Master配置?件 #不同步哪些數(shù)據庫 binlog-ignore-db=mysql binlog-ignore-db=test binlog-ignore-db=information_schema #同步哪些庫 binlog-do-db=game binlog-do-db=mydb #Slave配置?件 #復制哪些數(shù)據庫 replicate-do-db=mydb replicate-do-db=game #不復制哪些數(shù)據庫 replicate-ignore-db=mysql replicate-ignore-db=test --replicate-wild-ignore-table=foo%.bar% 不復制使?表名稱以開頭foo且表名稱以開頭 的表的更新bar
1.4.2.1. GTID的?式來進?主從復制
不同點 主從服務器的參數(shù)有不同的地? #在上?的基礎上,需要給主從服務器都加上 gtid_mode=on enforce_gtid_consistency=on #開啟強制GTID的?致性確保事務 GTID下復制鏈路的啟動 mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.102', MASTER_PORT=3306, MASTER_USER='syncuser', MASTER_PASSWORD='123456', MASTER_AUTO_POSITION=1; 啟動GTID后以下數(shù)據庫操作不可? create table tableName.... select 在?個事務中創(chuàng)建臨時表 在?個transaction中更新innoDB表和myisam表
2. 數(shù)據主從復制方式的容災處理
2.1. MySQL?持的復制格式
2.1.1. 基于語句的復制(statement)
優(yōu)點:記錄少,只記錄執(zhí)行語句,易懂
缺點:insert into table1(create_time) values(now()),這個now就不是當時的時間了
2.1.2. 基于行復制(row)
優(yōu)點:幾乎沒有基于行復制?法處理的場景
缺點:數(shù)據量太大了
2.1.3. 混合類型的復制(MIXED)
mixed格式默認采用statement,比如?到UUID(),ROW_COUNT()
2.1. MySQL主從復制模式
異步復制:MySQL默認就是異步復制,性能最好,但主從復制的數(shù)據不?致性概率最? 同步復制:當客戶端發(fā)過來?個請求后,只有當所有的從庫都寫到Relay Log中,才回復給前端事 務完成,性能最差,但?致性很強 半同步復制:?少?個從庫完成Relay Log寫?后就返回事務完成給前端 主從上都要安裝 mysql> install plugin rpl_semi_sync_master soname='semisync_master.so' rpl_semi_sync_master_enabled rpl_semi_sync_master_timeout #單位是毫秒,如果主庫等待從庫回復超過這個時間就?動切換 為異步
到此這篇關于MySQL數(shù)據庫高可用HA實現(xiàn)的文章就介紹到這了,更多相關MySQL數(shù)據庫高可用HA內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
詳解MySQL數(shù)據庫優(yōu)化的八種方式(經典必看)
關于數(shù)據庫優(yōu)化,網上有不少資料和方法,但是不少質量參差不齊,有些總結的不夠到位,內容冗雜。今天給大家分享一篇文章關于mysql數(shù)據庫優(yōu)化的八種方式,非常經典,需要的的朋友參考下2017-03-03MySQL同步ES(Elasticsearch)的四種常見方案分享
MySQL和Elasticsearch(ES)是兩個非常重要的數(shù)據存儲和搜索技術,MySQL是一種關系型數(shù)據庫,而ES則是一種文檔型數(shù)據庫,在許多情況下,我們需要將MySQL中的數(shù)據同步到ES中,本文將介紹四種常見的MySQL同步ES方案,需要的朋友可以參考下2023-07-07MySQL SELECT同時UPDATE同一張表問題發(fā)生及解決
例如用統(tǒng)計數(shù)據更新表的字段(此時需要用group子句返回統(tǒng)計值),從某一條記錄的字段update另一條記錄,而不必使用非標準的語句,等等感興趣的朋友可以參考下哈2013-03-03