MySQL數據庫⾼可⽤HA實現小結
MySQL數據庫⾼可⽤HA實現
1、 數據庫⾼可⽤分析
⾼可⽤的衡量標準
數據庫實現⾼可⽤的⼏種⽅式
MySQL數據庫實現⾼可⽤
2、MySQL主從復制的容災處理
MySQL⽀持的復制⽅式分析
主從場景切換⽅式
主從結構如何實現容災
1. 什麼是數據庫⾼可⽤
1.1. 什麼是⾼可⽤集群
N+1：N就是集群，1就是⾼可⽤，⾼可⽤的核⼼就是冗餘，集群是保證服務最低使⽤標準的
1.2. ⾼可⽤集群的衡量標準
⼀般是通過系統的可靠性和可維護性來衡量的
MTTF：平均⽆故障時間，這是衡量可靠性的
MTTR：衡量系統的可維護性的
HA=MTTF/(MTTF+MTTR)*100%
SLA：99.999%：表示⼀年故障時間/宕機時間不超過6分鐘
1.3. 實現⾼可⽤的三種⽅式
主從⽅式（⾮對稱）
這種⽅式的組織形式通常都是通過兩個節點和⼀個或多個服務器，其中⼀臺作為主節點
（active），另⼀臺作為備份節點（standy），備份節點應該隨時都在檢測主節點的健康狀況，當
主節點發⽣故障，服務會⾃動切換到備份節點保障服務正常運⾏
對稱⽅式
兩個節點，都運⾏著不同的服務且相互備份，相互檢測對⽅的健康，當任意⼀個節點發⽣故障，這
個節點上的服務就會⾃動切換到另⼀節點
多機⽅式
包含多個節點多個服務，每個節點都要備份運⾏不同的服務，出現問題⾃動遷移
1.4. MySQL數據的⾼可⽤實現
1.4.1. 主從⽅式（⾮對稱）
資源：兩臺同版本的MySQL數據庫
主從實現的內部運⾏原理和機制
First Step：主數據庫服務器會把數據的修改記錄記錄進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';
⽬前數據庫有兩種復制⽅式
binlog⽇志點position
GTID⽅式也要依賴binlog
第三步：從服務器的SQL進程會從Relay Log中讀取事件並在從庫中重放
從服務器執⾏重放操作時是可以在配置⾥聲明是否寫⼊服務器的binlog⽇志中
1.4.2. 配置主從服務步驟
1.4.2.1. Binlog的⽇志點⽅式配置主從同步
配置主從服務器參數
在Master服務器上創建⽤於復制並授權的數據庫賬號
備份Master數據庫並初始化Slave服務器數據
啟動復制鏈路
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損壞瞭，導致⼀部分中繼⽇志沒有處理，則放棄所有未完成的， 重新獲取執⾏，保證完整性 relay_log_recovery=1 #讓從庫數據隻讀，super⽤戶，super_read_only=on read_only=on #從庫的復制鏈路服務不會隨數據庫重啟⽽重啟，需要⼿動啟動 skip_slave_start=on #確保數據⼀致性，通過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;
初始化數據
mysqldump -uroot -p123456 --master-data=2 --single-transaction --routines - -triggers --events --databases mydb > mydb.sql
創建復制鏈路
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，所以性能會下降，如果需要在從庫上恢復數
據就到Relay Log⾥進⾏導出處理
直接在從庫上操作更⾏語句則會寫⼊binlog
如果就是需要寫⼊？在從庫的my.cnf : log_slave_updates=on #開啟同步並寫⼊binlog
開啟同步並寫⼊binlog應⽤於從到從的情況
問題：隻同步其中三個表
#Master配置⽂件 #不同步哪些數據庫 binlog-ignore-db=mysql binlog-ignore-db=test binlog-ignore-db=information_schema #同步哪些庫 binlog-do-db=game binlog-do-db=mydb #Slave配置⽂件 #復制哪些數據庫 replicate-do-db=mydb replicate-do-db=game #不復制哪些數據庫 replicate-ignore-db=mysql replicate-ignore-db=test --replicate-wild-ignore-table=foo%.bar% 不復制使⽤表名稱以開頭foo且表名稱以開頭 的表的更新bar
1.4.2.1. GTID的⽅式來進⾏主從復制
不同點 主從服務器的參數有不同的地⽅ #在上⾯的基礎上，需要給主從服務器都加上 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後以下數據庫操作不可⽤ create table tableName.... select 在⼀個事務中創建臨時表 在⼀個transaction中更新innoDB表和myisam表
2. 數據主從復制⽅式的容災處理
2.1. MySQL⽀持的復制格式
2.1.1. 基於語句的復制（statement）
優點：記錄少，隻記錄執⾏語句，易懂
缺點：insert into table1(create_time) values(now())，這個now就不是當時的時間瞭
2.1.2. 基於⾏復制（row）
優點：⼏乎沒有基於⾏復制⽆法處理的場景
缺點：數據量太⼤瞭
2.1.3. 混合類型的復制（MIXED）
mixed格式默認采⽤statement，⽐如⽤到UUID()，ROW_COUNT()
2.1. MySQL主從復制模式
異步復制：MySQL默認就是異步復制，性能最好，但主從復制的數據不⼀致性概率最⼤ 同步復制：當客戶端發過來⼀個請求後，隻有當所有的從庫都寫到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數據庫⾼可⽤HA實現的文章就介紹到這瞭,更多相關MySQL數據庫⾼可⽤HA內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！