MySQL高可用架構設計（主從複製）
1、MySQL複製功能提供分擔讀負載
複製解決了什麼問題？
1、 實現在不同伺服器上的資料分佈
利用二進位制日誌增量進行
不需要太多的頻寬
但是使用基於行的複製在進行大批量的更改時會對頻寬帶來一定的壓力
特別是跨IDC環境下進行復制應該分批進行。
2、實現資料讀取的負載均衡
需要其他元件配合完成
利用DNS輪詢的方式把程式的讀連線到不同的備份
使用LVS，haproxy這樣的代理方式
非共享架構，同樣的資料分佈在多臺伺服器上
3、增加了資料的安全性
利用備庫的備份來減少主庫負載
複製並不能代替備份
方便進行資料庫高可用架構的部署，避免MySQL單點失敗
4、實現資料庫高可用和故障切換
5、實現資料庫線上升級
2、MySQL二進位制日誌
二進位制日誌：記錄了所有對MySQL資料庫的修改事件，包括增刪改查事件和對錶結構的修改事件
二進位制日誌的格式：
基於段的日誌格式：binlog_format=STATEMENT
優點：1、日誌記錄量相對較小，節約磁碟及網路I/O
2、只對一條記錄修改或者插入
3、row格式所產生的日誌量小於段產生的日誌量
缺點：1、必須要記錄上下文資訊，保證語句在從伺服器上執行結果和在主伺服器上相同
2、特定函式UUID(),user()這樣非確定性函式還是無法複製，可能造成MySQL複製的主備伺服器資料不一致
基於行的日誌格式：binlog_format=ROW
ROW格式可以避免MySQL複製中出現主從不一致問題
優點：1、使用MySQL主從複製更加安全
2、對每一行資料的修改比基於段的複製高效
缺點：記錄日誌量較大
混合日誌格式：binlog_format=MIXED
特點：根據SQL語句由系統決在基於段和基於行的日誌格式中進行選擇
資料量的大小由所執行的SQL語句決定
3、MySQL複製工作方式
第一步：主將變更寫入二進位制日誌
第二步：從讀取二進位制日誌變更並寫入到relay_log中
基於日誌點的複製
基於GTID的複製
第三步：在從上重放relay_log中的日誌
基於SQL段的日誌是在從庫上重新執行記錄的SQL
基於行的日誌則是在從庫上直接應用對資料庫行的修改
4、基於日誌點的複製
操作步驟例子：
1、進行主伺服器的環境中：
2、建立資料庫使用者：
3、授權使用者：
4、退出
5、看看配置的引數
6、進行備份資料庫
7、將備份的檔案傳到從伺服器上
8、將檔案匯入到從資料庫
9、在從資料庫上進行復制鏈路的配置
10、看看從伺服器
11、啟動
12、看看主從上的程序
優點：
a、是MySQL最早支援的複製技術，Bug相對較少
b、對SQL查詢沒有任何限制
c、故障處理比較容易
缺點：
a、故障轉移時重新獲取新主的日誌點資訊比較困難
5、基於CTID的複製
什麼時GTID？
GTID即全域性事務ID，其保證為每一個在主上提交的事務在複製叢集中可以生成一個唯一的ID。
GTID=source_id:transaction_id
操作步驟例子：
1、進行主伺服器的環境中：
2、建立資料庫使用者：
3、授權使用者：
4、修改配置（主服務和從伺服器）
5、重啟伺服器
6、初始化資料
7、檢視all2.sql的內容
8、將備份的檔案傳到從伺服器上
9、將檔案匯入到從資料庫
10、在從資料庫上進行復制鏈路的配置
11、啟動
優點：
方便進行故障轉移
從庫不會丟失主庫上的任何修改
缺點：
故障處理比較複雜
對執行的SQL有一定限制
選擇複製模式考慮的問題
所使用的MYSQL版本（gtid是mysql5.6引入的新功能，早期的5.6版本也不建議使用gtid複製）
複製建構及主從切換的方式
所使用的高可用管理組建
對應用的支援程度