視頻教程傳送門 -> MySQL集羣解決方案（主從複製、PXC集羣、MyCat、HAProxy）https://www.bilibili.com/video/BV1R4411s7zi
目錄
MySQL數據庫的集羣方案
讀寫分離（主從複製）架構
MyCat數據庫中間件
HAProxy負載均衡
PXC集羣的使用
多種集羣架構綜合應用
1. MySQL數據庫的集羣方案
相對於單節點DB Server，集羣可以應對大併發、海量數據存儲等問題。下文以MySQL數據庫爲例。
一般應用對數據庫是“讀多寫少”，思路=> 採用數據庫集羣方案讀寫分離
其中一個是主庫，負責寫入數據 -> 寫庫
其它都是從庫，負責讀取數據 -> 從庫
需要遵循，
1）讀庫和寫庫數據一致
2）寫數據必須到寫庫
3）讀數據必須到讀庫
1.1 架構
說明：
數據庫從單節點變爲多節點提供服務
主節點數據同步到從節點（實際可有多個從節點）
應用程序需要連到2個數據庫節點，並在程序內部實現判斷讀寫操作
該架構存在的問題：
1）應用程序需要連接到多個節點，對應用程序而言開發變得複雜
解決：中間件;程序內部使用Spring的AOP功能實現
2）主從之間的同步，是異步完成 => 弱一致性
存在數據寫入主庫後應用程序讀取從庫獲取不到數據的情況，且可能丟失數據 =>不適合對數據安全要求較高的應用
解決：PXC集羣
1.2 中間件
說明：
應用程序無需連接到多個數據節點，連接到中間件即可
應用程序無需區分讀寫操作，對中間件直接進行讀寫操作即可
在中間件區分讀寫操作，讀發送到從節點，寫發送到主節點
該架構存在的問題：中間件的性能成爲了系統的瓶頸
解決：中間件做集羣
中間件的可靠性得到了保證，但也帶來了新的問題，應用系統需要連接到兩個中間件增加了複雜度
解決：負載均衡
1.3 負載均衡
在應用程序和中間件之間增加proxy代理
由代理來完成負載均衡的功能，應用程序只需對接到proxy即可
1.4 PXC集羣架構
前述的架構都是基於MySQL主從架構，問題：弱一致性
有的場景，如交易數據，需要強一致性
解決：PXC提供了讀寫強一致性的功能，可以保證數據在任何一個節點寫入的同時可以同步到其它節點
1.5 混合架構
在PXC架構中，實現了事務的強一致性，但是犧牲了性能
如果在某些業務的場景下沒有強一致性的需求，使用PXC不合適
因此可以將讀寫分離和PXC綜合起來，如下
2. 主從複製（讀寫分離）架構
環境說明：使用docker，MySQL使用衍生版Percona(版本5.7.23)；所有應用啓動在一臺服務器，所以有的地方需要修改端口
2.1 主從複製原理
master將數據改變記錄到二進制日誌(binary log)中，這些記錄叫做binary log events
slave將master的binary log events拷貝到它的中繼日誌(relay log)
slave重做中繼日誌中的事件
主從配置需要注意的地方：
1）主數據庫和從數據庫的版本一致
2）主數據庫和從數據庫數據一致
3）主數據庫開啓二進制日誌
4）主數據庫和從數據庫的server_id都必須唯一
2.2 主庫配置文件my.conf
編輯主庫my.cnf
#開啓主從複製
log-bin=mysql-bin
#指定主庫server-id
server-id=1
#指定同步的數據庫，如果不指定則同步全部數據庫
binlog-do-db=my_test
執行SQL語句查詢主庫狀態：SHOW MASTER STATUS
2.3 在主庫創建同步用戶
主庫執行如下語句
#授權用戶slave01使用密碼123456登錄MySQL
grant replication slave on *.* to 'slave01'@'127.0.0.1' identified by '123456';
#刷新配置
flush privileges;
2.4 從庫配置文件my.conf
編輯從庫my.conf
#指定server-id，不重複即可
server-id=2
執行以下SQL語句
CHANGE MASTER TO
master_host='127.0.0.1',
master_user='slave01',
master_password='123456',
master_port=3306,
master_log_file='mysql-bin.000006', #通過SHOW MASTER STATUS;查詢
master_log_pos=1120; #通過SHOW MASTER STATUS;查詢
啓動slave同步：START SLAVE;
查看同步狀態：SHOW SLAVE STATUS;
2.5 搭建主庫
2.6 搭建從庫
@關於binlog_format
MySQL提供3種模式
1)基於SQL語句的複製(statement-based replication,SBR)
2)基於行的複製(row-based replication,RBR)
3)混合模式複製(mixed-based replication,MBR)
binlog的模式也有三種:STATEMENT、ROW(默認)、MIXED(建議使用)
STATEMENT(SBR)
每一條修改數據的SQL語句都會記錄到binlog中
優點：不需要記錄每一條SQL語句和每一行的數據變化，減少binlog日誌量，節約IO，提高性能
缺點：某些情況會導致master-slave中的數據不一致，如SELECT NOW()
ROW(RBR)
不記錄每條SQL語句的上下文信息，僅需記錄哪條數據被修改了，修改成什麼樣了
會產生大量日誌，尤其是ALTER TABLE(在已有的表中添加、修改或刪除列)的時候會讓日誌暴漲
MIXED(MBR)
以上兩種模式的混合使用，
一般的複製使用STATEMENT模式保存binlog
對於STATEMENT模式無法複製的操作使用ROW模式保存binlog
MySQL會根據執行的SQL語句選擇日誌保存方式
3. MyCat中間件
3.1 讀寫分離
MySQL服務部署舉例
| 主機 | 端口 | 容器名稱 | 角色 |
| 192.168.1.18 | 3306 | percona-master01 | master |
| 192.168.1.18 | 3307 | percona-slave01 | slave |
step 1 編輯配置文件
(1）server.xml
(2）schema.xml
@balance屬性說明
代表負載均衡類型，取值說明如下
balance="0" 不開啓讀寫分離機制，所有讀操作都發送到當前可用的writeHost上
balance="1" 全部的readHost與standby writeHost參與select語句的負載均衡
即雙主從模式(M1->S1,M2->S2,並且M1和M2互爲主備)，M2,S1,S2都參與select語句的負載均衡
balance="2" 所有讀操作都隨機地在writeHost、readHost上分發
balance="3" 所有讀操作隨機地分發到writeHost對應地readHost執行，writeHost不負擔讀壓力
(3) rule.xml，因爲只有一個MySQL集羣，這裏count保持爲1
step 2 啓動MyCat
先使用命令./mycat console測試，如果顯示successfully就沒問題，再用命令./startup_nowrap.sh啓動
step3 連接Mycat
默認端口8806，可以再配置文件server.xml中修改
@搭建多節點MyCat
以上是搭建單節點MyCat步驟，如果需要搭建多節點MyCat參考如下
注：因爲放在一臺服務器，所以需要設置不同端口
3.2 數據分片
MySQL服務部署舉例
MySQL集羣1
| 主機 | 端口 | 容器名稱 | 角色 |
| 192.168.1.18 | 3306 | percona-master01 | master |
| 192.168.1.18 | 3307 | percona-slave01 | slave |
MySQL集羣2
| 主機 | 端口 | 容器名稱 | 角色 |
| 192.168.1.18 | 3316 | percona-master02 | master |
| 192.168.1.18 | 3317 | percona-slave02 | slave |
step 1 修改配置文件
配置schema.xml
配置rule.xml，因爲有兩個MySQL集羣，count設置爲2
<function name="mod long" class=xxx>
<property name="count">2</property>
</function>
4. HAProxy負載均衡
官網：http://www.haproxy.org
4.1 部署安裝HAProxy
拉取鏡像
docker pull haproxy:1.9.3
創建目錄，用於存放配置文件
mkdir /test/haproxy
創建容器
docker create --name haproxy --net host -v /test/haproxy:/usr/local/etc/haproxy haproxy：1.9.3
編輯配置文件
vim /test/haproxy/haproxy.cfg
可以根據以上配置打開URL查看MyCat狀態（如下，綠色爲正常運行）
5.PXC集羣的使用
Percona XtraDB Cluster(PXC)是針對MySQL用戶高可用性地擴展性解決方案，基於Percona Server。
Percona Server是MySQL的改進版本，使用XtraDB存儲引擎，提升了在高負載情況下的InnoDB的性能，另外有更多的參數和命令來控制服務器行爲。
PXC提供了，
同步複製，事務可以在所有節點上提交
多主機複製，可以寫到任意節點
從(slave)服務器上的並行應用事件，真正地並行複製
自動節點配置
數據一致性，不再有位同步地從服務器
5.1 部署安裝
部署三節點PXC舉例
| 節點 | 端口 | 容器名稱 | 數據卷 |
| node1 | 13306 | pxc_node1 | v1 |
| node2 | 13307 | pxc_node2 | v2 |
| node3 | 13308 | pxc_node3 | v3 |
具體步驟如下
注意：先啓動第一個節點，等mysql客戶端可以連接到服務後再啓動其它節點。
5.2 集羣的說明
儘可能控制PXC集羣規模，節點越多，數據同步速度越慢
所有PXC節點地硬件配置要一致，如果不一致，配置低地節點將拖慢數據同步速度
PXC集羣只支持InnoDB引擎，不支持其它地存儲引擎
@PXC集羣方案與Replication區別
| PXC | Replication |
| 所有節點都是可讀可寫的 | 從節點不能寫入，因爲主從同步是單向的 |
| 同步機制是同步進行的 | 同步機制是異步進行的 |
| 犧牲性能保證數據的一致性 | 性能上高於PXC |
| 用於重要信息的存儲，例如：訂單、用戶信息等 | 用於一般信息的存儲，能夠容忍數據丟失，例如：購物車、用戶行爲日誌等 |
6.多種集羣架構綜合應用
6.1 架構
說明：
HAProxy作爲負載均衡器
部署了2個MyCat節點作爲數據庫中間件
部署了2個PXC集羣節點，作爲2個 MyCat分片，每個PXC集羣中有2個節點，作爲數據的同步存儲
房源數據保存到PXC分片中，其餘數據如廣告保存到主從架構中（按表區分）
配置可以參考前述，需注意：
1）schema.xml文件前兩個集羣（PXC）balance設置爲2 -> 讀操作隨機到在writeHost、readHost），第三個集羣（主從）balance設置爲3 -> 讀操作隨機到writeHost對應地readHost執行，writeHost不負擔讀壓力。
2）schema.xml指定表給PXC或主從架構
