mysql高可用架構設計，處理高併發，大流量！

　　主要介紹：複製功能介紹、mysql二進制日誌、mysql複製拓撲、高可用框架、單點故障、讀寫分離和負載均衡介紹等

　　mysql複製功能介紹

　　mysql複製功能提供分擔讀負載

　　複製解決的問題

　　實如今不一樣服務器上的數據分佈

　　利用二進制日誌增量進行

　　不須要太多的帶寬

　　可是使用基於行的複製在進行大批量的更改時會對帶寬帶來必定得壓力，特別是跨IDC環境下進行復制

　　實如今不一樣服務器上的數據分佈

　　實現數據讀取的負載均衡

　　須要其餘組件配合完成

　　利用DNS輪詢的方式把程序的讀鏈接到不一樣的備份數據庫，

　　使用LVS，haproxy這樣的代理方式

　　非共享架構，一樣的數據分佈在多臺服務器上

　　加強了數據安全性

　　利用備庫的備份來減小主庫負載

　　複製並不能代替備份

　　實現數據庫高可用和故障切換

　　實現數據在線升級

　　mysql二進制日誌

　　mysql服務層日誌

　　二進制日誌

　　慢查日誌

　　通用日誌

　　mysql存儲引擎層日誌

　　innodb日誌

　　重作日誌

　　回滾日誌

　　

　　記錄了全部對mysql數據庫的修改事件，包括增刪改查事件和對錶結構的修改事件

　　

二進制日誌格式

　　基於段的格式(記錄sql語句)

　　binlog_format = statement

　　優勢

　　日誌記錄量相對較小，節約磁盤及網絡i/o, 只對一條記錄修改或者插入

　　缺點

　　必需要記錄上下文信息

　　保證語句在從服務器和主服務器上執行結果一致

　　對於特定的函數如uuid（），user()這樣非肯定性函數仍是沒法複製，可能形成mysql複製的主備服務器數據不一致

　　基於行的格式

　　binlog_format = ROW

　　同一sql語句修改了10000條數據的狀況下，基於段的日誌格式只會記錄這個sql語句，基於行的日誌格式會有10000條記錄分別記錄每一行的數據修改

　　優勢

　　使mysql主從複製更加安全

　　對每一行數據的修改比基於段的複製高效

　　誤操做而修改了數據庫中的數據，同時又沒有備份能夠恢復時，咱們就能夠經過分析二進制日誌，對日誌記錄的數據修改操做作反向處理的方式來達到恢復數據的目的。

　　缺點

　　記錄日誌格式較大

　　binlog_row_image = [full|minimal|noblob]

　　混合日誌格式

　　binlog_format = mixed
特色：

　　根據sql語句由系統決定在基於段和基於行的日誌格式中進行選擇

　　數據量的大小由所執行的sql語句決定

　　mysql二進制日誌格式對複製的影響

　　基於sql語句的複製（SBR）

　　優勢

　　生成的日誌量少，節約網絡傳輸i/o

　　並不強制要求主從數據庫的表定義徹底相同

　　相比於基於行的複製方式更爲靈活

　　缺點

　　對於非肯定事件，沒法保證主從複製數據的一致性

　　對於存儲過程、觸發器、自定義函數進行的修改也可能形成數據不一致

　　相比於基於行的複製方式在從上執行時須要更多的行鎖

　　基於行的複製

　　優勢

　　能夠應用於任何sql的複製包括非肯定函數，存儲過程等

　　能夠減小數據庫鎖的使用

　　缺點

　　要求主從數據的表結構相同，不然可能會中斷複製

　　沒法在從上單獨執行觸發器

　　mysql複製工做方式

　　

　　步驟

　　主將變動寫入二進制日誌

　　從讀取主的二進制日誌變動並寫入到relay_log中

　　基於日誌點的複製

　　基於GTID的複製

　　在從上重放relay_log中的日誌

　　基於sql段的日誌是在從庫上從新執行記錄的sql

　　基於行的日誌則是在從庫上直接應用對數據庫的修改

　　基於日誌點的複製

　　

　　基於日誌點複製配置步驟

　　在主DB服務器上創建複製帳號

　　create user 'repl' @'ip段'identified by 'password'

　　grant replication slave on . to 'repl' @'ip段‘

　　配置從數據庫服務器

　　bin_log = mysql-bin

　　server_id = 101

　　relay_log = mysql-relay-bin

　　log_slave_update = on

　　read_only = on

　　初始化從服務器數據

　　mysqldump --master-data=2 -single-transaction

　　xtrabackup --slave-info

　　啓動複製鏈路

　　change master to master_host="master_host_ip",master_user='repl',master_password='password' master_log_file='mysql_log_file_name',master_log_pos=4;

　　優缺點

　　優勢

　　是mysql最先支持的複製技術，bug相對較少

　　對sql查詢沒有任何限制

　　處理故障比較容易

　　缺點

　　故障轉移是從新獲取新主的日誌點信息比較困難

　　基於GTID的複製

　　

　　什麼是GTID

　　GTID即全局事務id，其保證爲每個在主上提交的事務在複製集羣中能夠生成一個惟一的id；GTID=source_id:transaction_id

　　

　　

　　bin_log = /usr/local/mysql/log/mysql-bin

　　server_id = 100

　　gtid_mode = on

　　enforce-gtid-consiste

　　啓動基於GTID的複製

　　change master to master_host="master_host_ip",master_user='repl',master_password='password'，master_auto_position = 1;

　　優缺點

　　優勢

　　能夠很方便的進行故障專業

　　從庫不會丟失主庫上的任何修改

　　缺點

　　故障處理比較複雜

　　對執行的sql有必定得限制

　　選擇複製模式要考慮的問題

　　所使用的mysql版本

　　複製架構及主從切換的方式

　　所使用的高可用管理組件

　　對應用的支持程度

　　mysql複製拓撲

　　

　　mysql5.7以前，一個從庫只能有一個主庫

　　mysql5.7以後，支持一從多主架構

　　一主多從的複製拓撲

　　

　　優勢

　　配置簡單

　　能夠用多個從庫分擔讀負載

　　用途

　　爲不一樣業務使用不一樣的從庫

　　將一臺從庫放到遠程IDC，用做災備恢復

　　分擔主庫的讀負載

　　主-主複製拓撲

　　

　　配置注意事項

　　兩個主中所操做的表最好可以分開

　　使用下面兩個參數控制自增id的生成

　　auto_increment_increment = 2

　　auto_increment_offset = 1 | 2

　　主備模式下的主-主複製配置主要事項

　　只有一臺主服務器對外提供服務

　　一臺服務器處於只讀狀態而且只做爲熱備使用

　　在對外提供服務的主庫出現故障或是計劃性的維護時纔會進行切換

　　使原來的備庫成爲主庫，而原來的主庫會成爲新的備庫，並處理只讀或是下線狀態，待維護完成後從新上線

　　確保兩臺服務器上的初始數據相同

　　確保兩臺服務器上已經啓動binlog而且有不一樣的server_id

　　在初始的備份上啓用read_only

　　也能夠給主庫分配幾個從庫

　　

　　級聯複製

　　

　　mysql複製性能優化

　　影響主從延遲的因素

　　

　　主庫寫入二進制日誌的時間

　　解決方法：控制主庫的事務大小，分割大事務

　　二進制日誌傳輸時間

　　解決方法：使用mixed日誌格式或設置set binlog_row_image=minimal

　　默認狀況下從庫只有一個sql線程，主上併發的修改在從上變成了串行

　　解決方法：使用多線程複製，在mysql5.7中能夠按照邏輯時鐘的方式來分配sql線程

　　配置步驟：

　　stop slave

　　set global slave_parallel_type = 'logical_clock'

　　set global slave_parallel_workers = 4

　　start slave

　　mysql複製常見問題處理

　　因爲數據損壞或丟失所引發的主從複製錯誤

　　主庫或者從庫意外宕機引發的錯誤

　　解決方法：

　　使用跳過二進制日誌事件

　　注入空事務的方式先恢復中斷的複製鏈路

　　再使用其它方法來對比主從服務器上的數據

　　主庫上的二進制日誌損壞

　　備庫上的中繼日誌損壞

　　在從庫上進行數據修改形成的主從複製錯誤

　　mysql複製沒法解決的問題

　　分擔數據庫的寫負載

　　自動進行故障轉移及主從切換

　　提供讀寫分離功能

　　高可用框架 什麼是高可用

　　高可用H.A(High Avalilability)指的是經過儘可能縮短因平常維護操做（計劃）和突發的系統崩潰（非計劃）所致使的停機時間，以提升系統和應用的可用性

　　

　　表示高可用經常使用的因子

　　正常可用時間

　　整年時間百分比

　　引發系統不可用的緣由

　　嚴重的主從延遲

　　主從複製中斷

　　鎖引發的大量阻塞

　　軟硬件故障形成的服務器宕機等

　　如何實現高可用

　　避免致使系統不可用的因素，減小系統不可用的時間

　　創建完善的監控及報警系統

　　對備份數據進行恢復測試

　　正確配置數據庫環境

　　對不須要的數據進行歸檔和清理

　　增長系統冗餘，保證發生系統不可用時能夠儘快恢復

　　避免存在單點故障

　　主從切換及故障轉移

　　緣由

　　有服務器磁盤空間耗盡、

　　性能糟糕的sql

　　表結構和索引沒有優化

　　主從數據不一致

　　人爲的操做失誤

　　單點故障

　　單點故障是指在一個系統中提供相同功能的組件只有一個，若是這個組件失效了，就會影響整個系統的正常使用。組成應用系統的各個組件都有可能成爲單點。

　　

　　如何避免mysql單點故障

　　利用sun共享存儲或drdb磁盤複製解決mysql單點故障

　　sun

　　

　　drdb

　　

　　利用多寫集羣或ndb集羣來解決mysql單點故障

　　

　　如何解決主服務器的單點問題

　　主服務器切換後，如何通知應用新的主服務器的ip地址

　　如何檢查mysql主服務器是否可用

　　如何處理從服務器和新主服務器之間的那種複製關係

　　MMM架構介紹

　　Multi-Master Replication Manager

　　

MMM提供了什麼功能

　　MMM監控mysql主從複製健康狀況

　　在主庫出現宕機時進行故障轉移並自動配置其餘從對主的複製

　　如何找到從庫對應的新的主庫日誌點的日誌同步點

　　若是存在多個從庫出現數據不一致的狀況如何處理

　　提供了讀、寫虛擬ip， 在主服務器出現問題時，能夠自動遷移虛擬ip

　　MMM架構

　　

　　MMM部署所需資源

　　

　　MMM優缺點

　　優勢

　　使用perl腳本語言開發及徹底開源

　　提供了讀寫vip（虛擬ip），使服務器角色的變動對前端應用透明

　　MMM提供了從服務器的延遲監控

　　缺點

　　發佈時間比較早不支持mysql新的複製功能

　　沒有讀負載的功能

　　在進行主從切換時，容易形成數據丟失

　　MMM監控服務存在單點故障

　　MHA架構介紹

　　Master High Avalilability

　　

　　提供的功能

　　監控主數據庫服務是否可用

　　當主DB不可用時，從多個從服務器中選舉出新的主數據庫服務器

　　提供了主從切換和故障轉移功能

　　MHA主從切換過程

　　嘗試從出現故障的主數據庫保存二進制日誌

　　從多個備選從服務器中選舉新的備選主服務器

　　在備選主服務器和其餘從服務器之間同步差別二進制數據

　　應用從原db服務器上保存的二進制日誌

　　讀寫分離和負載均衡介紹

　　進行mysql主從複製配置的一個主要目的：爲了分擔主庫的讀負載

　　爲何要讀寫分離

　　只能在主上進行寫操做

　　讀操做主和從上均可以

　　

　　讀寫分離的兩種方式

　　程序實現讀寫分離

　　優勢

　　由開發人員控制什麼樣查詢在從庫中執行，所以比較靈活

　　有程序直接鏈接數據庫，因此性能損耗比較少

　　缺點

　　增長了開發的工做量，使程序代碼更加複雜

　　認爲控制，容易出現錯誤

　　中間件實現讀寫分離

　　優勢

　　由中間件根據查詢語法分析，自動完成讀寫分離

　　對程序透明，對於已有程序不用作任何調整

　　缺點

　　增長了中間層，因此對查詢效率有損耗

　　對於延遲敏感業務沒法自動在主庫執行

　　讀寫分離與讀的負載均衡區別

　　讀寫分離要解決的是如何在複製集羣的不一樣角色上，去執行不一樣的sql語句

　　讀的負載均衡主要解決的是具備相同角色的數據庫，如何共同分擔相同的負載

　　如何實現讀的負載均衡

　　軟件

　　LVS

　　Haproxy

　　MaxScale

　　硬件

　　F5