主要介紹：複製功能介紹、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