從單機到集群
隨着數據量增加，讀寫並發的增加，系統可用性要求的提升，單機MySQL存在着一些問題：
- 容量有限，難以擴容
- 讀寫壓力、QPS過大，特別是分析類需求會影響到業務事務
- 可用性不足，單點故障
1 主從復制
核心流程是：
- 主庫寫binlog
- 從庫拉取binlog寫入relay log
binlog格式
- Row
這個模式存的是哪條記錄被修改，修改成什么樣.缺點是日志內容大。
- Statement
存的是sql語句,日志量少。缺點是一些函數、觸發器同步可能有障礙。
- Mixed
兩種模式的結合，根據執行的sql語句來區分對待記錄的日志形式。
查看binlog命令，進入mysql的bin目錄下執行。
mysqlbinlog --no-defaults ../data/binlog.000116
修改binlog模式
- 先查看binlog格式
SHOW VARIABLES LIKE "%binlog_format%";
- 在線修改
set global binlog_format='MIXED';
- 使用配置修改
配置文件my.ini中加入
binlog_format="MIXED" #開啟MIXED模式
修改后重啟mysql服務
主從復制方案
- 異步復制
傳統的主從復制，網絡或機器故障，會導致數據不一致
- 半同步復制
保證Source和Replica最終一致性
- 組復制 （Mysql Group Replication)
簡稱MGR，基於分布式協議Paxos實現，保證數據一致性
主從復制實戰
異步復制
- 准備兩個mysql實例
- 修改master的那個mysql實例的my.cnf配置文件，增加如下內容,並重啟mysql
server-id=1
log-bin=mysql-bin
- 登入master的mysql，創建一個同步數據的用戶
CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
- 修改slave的那個mysql實例的my.cnf配置文件，增加如下內容，並重啟mysql
server-id=2
log-bin=mysql-bin
- 登入master的mysql，執行
show master status;
記錄下File和Position
- 登入slave的mysql，配置從庫
change master to master_host='192.168.161.21', master_user='slave', master_password='123456', master_port=3306, master_log_file='mysql-bin.000001', master_log_pos= 837, master_connect_retry=30;
master_log_file和master_log_pos就是上面記錄下的File和Position。
執行完后繼續執行下面的命令，開啟主從復制
start slave
- 查看主從復制是否生效
show slave status \G;
兩個都是YES，說明成功
- 測試，在主庫上新建數據庫，新建表，插入數據，然后查看從庫的數據情況即可。
主從復制的局限性
- 主從延遲問題
- 應用端需要配合讀寫分離框架
- 不解決高可用的問題
2 讀寫分離
方案1：
基於Spring提供的路由數據源AbstractRoutingDataSource以及AOP
缺點：
- 代碼侵入性強
- 同一個service中有“寫完讀”數據不一致問題
具體實現：https://www.cnblogs.com/cjsblog/p/9712457.html
方案2：
ShardingSphere-jdbc 的 Master-Slave 功能
缺點：
- 對業務系統還是有侵入
- 對已存在的舊系統改造不友好
具體操作：https://www.cnblogs.com/javammc/p/12470838.html
方案3：
使用MyCat/ShardingSphere-Proxy的Master-Slave功能
部署中間件，規則配置在中間件中，業務系統無侵入。
3 MySQL高可用
什么是高可用？
高可用代表着更少的不可服務的時間。一般互聯網公司要求達到4個9,即一年不能服務的時間不超過52.6分鍾
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小時
99.99 = 8760 * 0.0001 = 0.876小時 = 0.876 * 60 = 52.6分鍾
數據庫要實現高可用，需要做到
- 讀寫分離，提高讀的處理能力
- 故障轉移，災難恢復
常見的一些策略有：
- 多個實例不在一個主機上
- 跨機房部署
- 兩地三中心容災高可用方案
3.1 MySQL高可用方案
方案1：主從手動切換
如果主節點掛掉了，將某個從改為主。然后配置其他從節點。應用側需要修改數據源配置。
缺點：
- 可能數據不一致
- 需要人工操作
- 代碼和配置的侵入性
方案2：主從手動切換2
用LVS+Keepalived實現多個節點的探活+請求路由
，配置VIP或DNS實現應用側配置不變更
缺點：
- 也需要手工操作
- 大量的配置和腳本定義
方案3：MHA
MHA（Master High Availability）目前在 MySQL 高可用方面是一個相對成熟的解決方案，它由日本 DeNA 公司的 youshimaton（現就職於 Facebook 公司）開發，是一套優秀的作為 MySQL 高可用性環境下故障切換和主從提升的高可用軟件。
基於Perl語言開發，一般能在30S內實現主從切換。切換時通過SSh復制主節點的日志。
缺點：
- 需要配置SSH信息
- 至少3台機器
方案4：MGR
Mysql Group Replication(MGR)
MGR的特點：
- 高一致性：基於分布式協議Paxos實現組復制，保證數據一致性
- 高容錯性：自動檢測機制，只要不是大多數節點宕機都可以繼續工作
- 高擴展性：節點的的增加與移除會自動更新組成員信息。新節點加入后，自動從其他節點通過增量數據，直到與其他節點數據一致
- 高靈活性：提高單主模式和多主模式，單主模式在主庫宕機后自動選主，多主模式支持多節點寫入。
如果主節點掛掉，將自動選擇某個從改為主。無需人工干預，基於組復制，保證數據一致性。
缺點：
- 外部獲得狀態變更需要讀取數據庫
- 外部需要使用LVS/VIP配置
方案5：Mysql Cluster
MySQL InnoDB Cluster是一個高可用的框架，它由下面這幾個組件構成：
- MySQL Group Replication :提供DB的擴展、自動故障轉移
- MySQL Router:輕量級中間件，提供應用程序負載均衡和應用連接的故障轉移
- MySQL Shell：新的MySQL客戶端，多種接口模式
方案6：orchestrator
一款MySQL高可用和復制拓撲管理工具，支持自動故障轉移和手動主從切換等。通過Web界面操作可以更改Mysql實例的復制關系和部分配置信息，同時提供命令行和API接口，方便運維管理。