MySQL數(shù)據(jù)庫高可用HA實現(xiàn)

1、 數(shù)據(jù)庫高可用分析

高可用的衡量標(biāo)準(zhǔn)
數(shù)據(jù)庫實現(xiàn)高可用的幾種?式
MySQL數(shù)據(jù)庫實現(xiàn)高可用

2、MySQL主從復(fù)制的容災(zāi)處理

MySQL支持的復(fù)制方式分析
主從場景切換方式
主從結(jié)構(gòu)如何實現(xiàn)容災(zāi)

1. 什么是數(shù)據(jù)庫高可用

1.1. 什么是高可用集群

N+1：N就是集群，1就是高可用，?可?的核?就是冗余，集群是保證服務(wù)最低使用標(biāo)準(zhǔn)的

1.2. 高可用集群的衡量標(biāo)準(zhǔn)

一般是通過系統(tǒng)的可靠性和可維護(hù)性來衡量的
MTTF：平均無故障時間，這是衡量可靠性的
MTTR：衡量系統(tǒng)的可維護(hù)性的
HA=MTTF/(MTTF+MTTR)*100%
SLA：99.999%：表示?年故障時間/宕機(jī)時間不超過6分鐘

1.3. 實現(xiàn)高可用的三種方式

主從方式（?對稱）
    這種?式的組織形式通常都是通過兩個節(jié)點和?個或多個服務(wù)器，其中?臺作為主節(jié)點
（active），另?臺作為備份節(jié)點（standy），備份節(jié)點應(yīng)該隨時都在檢測主節(jié)點的健康狀況，當(dāng)
    主節(jié)點發(fā)?故障，服務(wù)會?動切換到備份節(jié)點保障服務(wù)正常運(yùn)?
對稱?式
    兩個節(jié)點，都運(yùn)?著不同的服務(wù)且相互備份，相互檢測對?的健康，當(dāng)任意?個節(jié)點發(fā)?故障，這
    個節(jié)點上的服務(wù)就會?動切換到另?節(jié)點
多機(jī)方式
    包含多個節(jié)點多個服務(wù)，每個節(jié)點都要備份運(yùn)?不同的服務(wù)，出現(xiàn)問題?動遷移

1.4. MySQL數(shù)據(jù)的高可用實現(xiàn)

1.4.1. 主從方式（?對稱）

資源：兩臺同版本的MySQL數(shù)據(jù)庫
主從實現(xiàn)的內(nèi)部運(yùn)行原理和機(jī)制
    First Step：主數(shù)據(jù)庫服務(wù)器會把數(shù)據(jù)的修改記錄記錄進(jìn)binlog?志，binlog?定要打開
    Second Step：從庫的I/O進(jìn)行讀取主庫的binlog內(nèi)容后存???的Relay Log中繼?志中，這
    個I/O線程會和主庫建??個普通的客戶端連接，然后主庫啟動?個?進(jìn)制轉(zhuǎn)儲線程，I/O線
    程通過轉(zhuǎn)儲線程讀取binlog更新事件，同步完畢后I/O進(jìn)?sleep，有新的更新會再喚醒
            Relay Log和Binlog的格式是?樣的，可以?mysqlbinlog讀取，也可show
            mysql> show relaylog events in 'relay-log.000001';
            ?前數(shù)據(jù)庫有兩種復(fù)制?式
                    binlog?志點position
                    GTID?式也要依賴binlog
    第三步：從服務(wù)器的SQL進(jìn)程會從Relay Log中讀取事件并在從庫中重放
            從服務(wù)器執(zhí)?重放操作時是可以在配置?聲明是否寫?服務(wù)器的binlog?志中

1.4.2. 配置主從服務(wù)步驟

1.4.2.1. Binlog的?志點?式配置主從同步

配置主從服務(wù)器參數(shù)
在Master服務(wù)器上創(chuàng)建?于復(fù)制并授權(quán)的數(shù)據(jù)庫賬號
備份Master數(shù)據(jù)庫并初始化Slave服務(wù)器數(shù)據(jù)
啟動復(fù)制鏈路

Master服務(wù)器配置

chown -R mysql:mysql /usr/local/binlog/
#配置?件
server_id=163
log_bin=/usr/local/binlog/mysql-bin
12345

Slave服務(wù)器配置

server_id=196
log_bin=/usr/local/binlog/mysql-bin
relay_log=/usr/local/relaylog/relay-bin
#當(dāng)slave宕機(jī)后，如果relay log損壞了，導(dǎo)致?部分中繼?志沒有處理，則放棄所有未完成的，
重新獲取執(zhí)行，保證完整性
relay_log_recovery=1 #讓從庫數(shù)據(jù)只讀，super用戶，super_read_only=on
read_only=on
#從庫的復(fù)制鏈路服務(wù)不會隨數(shù)據(jù)庫重啟而重啟，需要手動啟動
skip_slave_start=on
#確保數(shù)據(jù)?致性，通過innoDB的崩潰恢復(fù)機(jī)制來保護(hù)哦
master_info_repository=TABLE
relay_log_info_repository=TABLE
#select * from mysql.slave_master_info;
#select * from mysql.slave_relay_log_info;

主庫授權(quán)

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ù)據(jù)

mysqldump -uroot -p123456 --master-data=2 --single-transaction --routines -
-triggers --events --databases mydb > mydb.sql

創(chuàng)建復(fù)制鏈路

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是否寫?？

默認(rèn)情況下是不寫入的：因為寫入binlog會消耗I/O，所以性能會下降，如果需要在從庫上恢復(fù)數(shù)
據(jù)就到Relay Log里進(jìn)?導(dǎo)出處理
直接在從庫上操作更?語句則會寫入binlog
如果就是需要寫入？在從庫的my.cnf : log_slave_updates=on #開啟同步并寫入binlog
開啟同步并寫入binlog應(yīng)用于從到從的情況

問題：只同步其中三個表

#Master配置?件
#不同步哪些數(shù)據(jù)庫
binlog-ignore-db=mysql
binlog-ignore-db=test
binlog-ignore-db=information_schema
#同步哪些庫
binlog-do-db=game
binlog-do-db=mydb

#Slave配置?件
#復(fù)制哪些數(shù)據(jù)庫
replicate-do-db=mydb
replicate-do-db=game
#不復(fù)制哪些數(shù)據(jù)庫
replicate-ignore-db=mysql
replicate-ignore-db=test

--replicate-wild-ignore-table=foo%.bar% 不復(fù)制使?表名稱以開頭foo且表名稱以開頭
的表的更新bar

1.4.2.1. GTID的?式來進(jìn)?主從復(fù)制

不同點
	主從服務(wù)器的參數(shù)有不同的地?

#在上?的基礎(chǔ)上，需要給主從服務(wù)器都加上
gtid_mode=on
enforce_gtid_consistency=on #開啟強(qiáng)制GTID的?致性確保事務(wù)		

GTID下復(fù)制鏈路的啟動
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ù)據(jù)庫操作不可?
	create table tableName.... select
	在?個事務(wù)中創(chuàng)建臨時表
	在?個transaction中更新innoDB表和myisam表

2. 數(shù)據(jù)主從復(fù)制方式的容災(zāi)處理

2.1. MySQL?持的復(fù)制格式

2.1.1. 基于語句的復(fù)制（statement）

優(yōu)點：記錄少，只記錄執(zhí)行語句，易懂
    缺點：insert into table1(create_time) values(now())，這個now就不是當(dāng)時的時間了

2.1.2. 基于行復(fù)制（row）

優(yōu)點：幾乎沒有基于行復(fù)制?法處理的場景
    缺點：數(shù)據(jù)量太大了

2.1.3. 混合類型的復(fù)制（MIXED）

mixed格式默認(rèn)采用statement，比如?到UUID()，ROW_COUNT()

2.1. MySQL主從復(fù)制模式

異步復(fù)制：MySQL默認(rèn)就是異步復(fù)制，性能最好，但主從復(fù)制的數(shù)據(jù)不?致性概率最?
同步復(fù)制：當(dāng)客戶端發(fā)過來?個請求后，只有當(dāng)所有的從庫都寫到Relay Log中，才回復(fù)給前端事
務(wù)完成，性能最差，但?致性很強(qiáng)
半同步復(fù)制：?少?個從庫完成Relay Log寫?后就返回事務(wù)完成給前端

主從上都要安裝
mysql> install plugin rpl_semi_sync_master soname='semisync_master.so'
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout #單位是毫秒，如果主庫等待從庫回復(fù)超過這個時間就?動切換
為異步

到此這篇關(guān)于MySQL數(shù)據(jù)庫高可用HA實現(xiàn)的文章就介紹到這了,更多相關(guān)MySQL數(shù)據(jù)庫高可用HA內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論