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

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

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

2、MySQL主從復制的容災處理

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

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

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ù)據(jù)的高可用實現(xiàn)

1.4.1. 主從方式（?對稱）

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

1.4.2. 配置主從服務步驟

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

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

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ù)據(jù)只讀，super用戶，super_read_only=on
read_only=on
#從庫的復制鏈路服務不會隨數(shù)據(jù)庫重啟而重啟，需要手動啟動
skip_slave_start=on
#確保數(shù)據(jù)?致性，通過innoDB的崩潰恢復機制來保護哦
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)建復制鏈路

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ù)
據(jù)就到Relay Log里進?導出處理
直接在從庫上操作更?語句則會寫入binlog
如果就是需要寫入？在從庫的my.cnf : log_slave_updates=on #開啟同步并寫入binlog
開啟同步并寫入binlog應用于從到從的情況

問題：只同步其中三個表

#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配置?件
#復制哪些數(shù)據(jù)庫
replicate-do-db=mydb
replicate-do-db=game
#不復制哪些數(shù)據(jù)庫
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ù)據(jù)庫操作不可?
	create table tableName.... select
	在?個事務中創(chuàng)建臨時表
	在?個transaction中更新innoDB表和myisam表

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

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ù)據(jù)量太大了

2.1.3. 混合類型的復制（MIXED）

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

2.1. MySQL主從復制模式

異步復制：MySQL默認就是異步復制，性能最好，但主從復制的數(shù)據(jù)不?致性概率最?
同步復制：當客戶端發(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 #單位是毫秒，如果主庫等待從庫回復超過這個時間就?動切換
為異步

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

最新評論