案例：
100W 的客戶端，每三分鐘上傳一次數據。數據庫如何設計？能夠查詢所有記錄？
官方 MySQL 集群方案
MySQL Replication
MySQL Replication 是 mysql 自帶的功能，主從復制是通過重放 binlog 實現主庫數據的
異步復制。即當主庫執行了一條 sql 命令，那么在從庫同樣地執行一遍，從而達到主從復制
的效果。在這個過程中，master 對數據的寫操作記入二進制日志文件中(binlog)，生成一
個 log dump 線程，用來給從庫的 i/o 線程傳 binlog。而從庫的 i/o 線程去請求主庫的
binlog，并將得到的 binlog 日志寫到中繼日志（relaylog）中，從庫的 sql 線程，會讀
取 relaylog 文件中的日志，并解析成具體操作，通過主從的操作一致，而達到最終數據一
致。
MySQL Replication 一主多從的結構，主要目的是實現數據的多點備份（沒有故障自動轉移和
負載均衡）。相比于單個的 mysql，一主多從下的優勢如下：
1. 如果讓后臺讀操作連接從數據庫，讓寫操作連接主數據庫，能起到讀寫分離的作用，這
個時候多個從數據庫可以做負載均衡。
2. 可以在某個從數據庫中暫時中斷復制進程，來備份數據，從而不影響主數據的對外服務
（如果在 master 上執行 backup，需要讓 master 處于 readonly 狀態，這也意味著所有的
write 請求需要阻塞）。
就各個集群方案來說，其優勢為：
1. 主從復制是 mysql 自帶的，無需借助第三方。
2. 數據被刪除，可以從 binlog 日志中恢復。
3. 配置較為簡單方便。
其劣勢為：
1. 從庫要從 binlog 獲取數據并重放，這肯定與主庫寫入數據存在時間延遲，因此從庫的數
據總是要滯后主庫。
2. 對主庫與從庫之間的網絡延遲要求較高，若網絡延遲太高，將加重上述的滯后，造成最
終數據的不一致。
3. 單一的主節點掛了，將不能對外提供寫服務。
配置主機：
$ sudo vim /etc/mysql/my.cnf
添加 log-bin , server_id
修改 bind-address = 0.0.0.0
mysql > create user replication@'%' identified by '123456';
mysql > grant all privileges on *.* to 'replication'@'%' identified by '123456' with grant option;
mysql > show master status;
配置從機
mysql > change master to master_host='192.168.189.133', master_port=3306,
master_user='replication', master_password='123456', master_log_file='mysql-bin.000001',
master_log_pos=380;
mysql > start slave;
mysql> show slave statusG
問題 1
# mysql –u root -p
> create user ‘wangbojing’@’%’ identified by ‘123456’;
> grant all privileges on *.* to ‘wangbojing’@’%’ identified by
‘123456’ with grant option;
> SHOW DATABASES;
> CREATE DATABASE VIP_ORDER;
> CREATE TABLE TBL_USER (
> U_ID INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
> U_NAME VARCHAR(64) NOT NULL,
> U_IMAGE LONGBLOB,
> U_GENDER VARCHAR(64)
> )
# 性能測試
# sysbench src/lua/oltp_read_write.lua --tables=3 --table_size=500000 -
-mysql-user=root --mysql-password=123456 --mysql-host=192.168.2.217
mysql-port=3306 --mysql-db=TBL_REPLICATION prepare
# sysbench src/lua/oltp_point_select.lua --tables=3 --table_size=500000 --mysql
user=root --mysql-password=zhaomeiping --mysql-host=192.168.2.217 --mysql-port=3306
--mysql-db=TBL_REPLICATION --threads=128 --time=100 --report-interval=5 run
MySQL Fabirc
MySQL Fabirc，是 mysql 官方提供的。這是在 MySQL Replication 的基礎上，增加了故障檢測
與轉移，自動數據分片功能。不過依舊是一主多從的結構，MySQL Fabirc 只有一個主節點，
區別是當該主節點掛了以后，會從從節點中選擇一個來當主節點。
就各個集群方案來說，其優勢為：
1. mysql 官方提供的工具，無需第三方插件。
2. 數據被刪除，可以從 binlog 日志中恢復。
3. 主節點掛了以后，能夠自動從從節點中選擇一個來當主節點，不影響持續對外提供寫服
務。
其劣勢為：
1. 從庫要從 binlog 獲取數據并重放，這肯定與主庫寫入數據存在時間延遲，因此從庫的數
據總是要滯后主庫。
2. 對主庫與從庫之間的網絡延遲要求較高，若網絡延遲太高，將加重上述的滯后，造成最
終數據的不一致。
3. 2014 年 5 月推出的產品，數據庫資歷較淺，應用案例不多，網上各種資料相對較少。
4. 事務及查詢只支持在同一個分片內，事務中更新的數據不能跨分片，查詢語句返回的數
據也不能跨分片。
5. 節點故障恢復 30 秒或更長（采用 InnoDB 存儲引擎的都這樣）。
MySQL Cluster
MySQL 集群（MySQL Cluster）也是 mysql 官方提供的。
MySQL Cluster 是多主多從結構的
就各個集群方案來說，其優勢為：
1.
mysql 官方提供的工具，無需第三方插件。
2.
高可用性優秀，99.999%的可用性，可以自動切分數據，能跨節點冗余數據（其數據集并
不是存儲某個特定的 MySQL 實例上，而是被分布在多個 Data Nodes 中，即一個 table 的
數據可能被分散在多個物理節點上，任何數據都會在多個 Data Nodes 上冗余備份。任何
一個數據變更操作，都將在一組 Data Nodes 上同步，以保證數據的一致性）。
3.
可伸縮性優秀，能自動切分數據，方便數據庫的水平拓展。
4.
負載均衡優秀，可同時用于讀操作、寫操作都都密集的應用，也可以使用 SQL 和 NOSQL
接口訪問數據。
5.
多個主節點，沒有單點故障的問題，節點故障恢復通常小于 1 秒。
其劣勢為：
1. 架構模式和原理很復雜。
2. 只能使用存儲引擎 NDB ，與平常使用的 InnoDB 有很多明顯的差距。比如在事務（其
事務隔離級別只支持 Read Committed，即一個事務在提交前，查詢不到在事務內所做的
修改），外鍵（雖然最新的 NDB 存儲引擎已經支持外鍵，但性能有問題，因為外鍵所關
聯的記錄可能在別的分片節點），表現制上的不同，可能會導致日常開發出現意外。
3. 作為分布式的數據庫系統，各個節點之間存在大量的數據通訊，比如所有訪問都是需要
經過超過一個節點（至少有一個 SQL Node 和一個 NDB Node）才能完成，因此對節點之
間的內部互聯網絡帶寬要求高。
4. Data Node 數據會被盡量放在內存中，對內存要求大，而且重啟的時候，數據節點將數
據 load 到內存需要很長時間。
第三方集群方案
MMM
MMM（Master Replication Manager for MySQL）是雙主多從結構，MMM 是在 MySQL Replication
的基礎上，對其進行優化。這是 google 的開源項目，使用 Perl 語言來對 MySQL Replication
做擴展，提供一套支持雙主故障切換和雙主日常管理的腳本程序，主要用來監控 mysql 主主
復制并做失敗轉移。
注意：這里的雙主節點，雖然叫做雙主復制，但是業務上同一時刻只允許對一個主進行寫入，
另一臺備選主上提供部分讀服務，以加速在主主切換時刻備選主的預熱。
就各個集群方案來說，其優勢為：
1. 自動的主主 Failover 切換，一般 3s 以內切換備機。
2. 多個從節點讀的負載均衡。
其劣勢為：
1. 無法完全保證數據的一致性。如主 1 掛了，MMM monitor 已經切換到主 2 上來了，而若
此時雙主復制中，主 2 數據落后于主 1（即還未完全復制完畢），那么此時的主 2 已經成
為主節點，對外提供寫服務，從而導致數據不一。
2. 由于是使用虛擬 IP 浮動技術，類似 Keepalived，故 RIP（真實 IP）要和 VIP（虛擬 IP）在
同一網段。如果是在不同網段也可以，需要用到虛擬路由技術。但是絕對要在同一個 IDC
機房，不可跨 IDC 機房組建集群。
MHA
MHA（Master High Availability）是多主多從結構，MHA 是在 MySQL Replication 的基礎上，對
其進行優化。這是日本 DeNA 公司的 youshimaton 開發，主要提供更多的主節點，但是缺少
VIP（虛擬 IP），需要配合 keepalived 等一起使用。
要搭建 MHA，要求一個復制集群中必須最少有三臺數據庫服務器，一主二從，即一臺充當
master，一臺充當備用 master，另外一臺充當從庫。
就各個集群方案來說，其優勢為：
1. 可以進行故障的自動檢測和轉移
2. 具備自動數據補償能力，在主庫異常崩潰時能夠最大程度地保證數據的一致性。
其劣勢為：
1. MHA 架構實現讀寫分離，最佳實踐是在應用開發設計時提前規劃讀寫分離事宜，再使用
時設置兩個連接池，即讀連接池與寫連接池，也可以選擇這種方案即引入 SQL Proxy。但
無論如何都需要改動代碼；
2. 關于讀負載均衡可以使用 F5、LVS、HAPROXY 或者 SQL Proxy 等工具，只要能實現負載均
衡、故障檢查及備升級為主后的讀寫剝離功能即可，建議使用 LVS
Galera Cluster
Galera Cluster 是由 Codership 開發的 MySQL 多主結構集群，這些主節點互為其它節點的從節
點。不同于 MySQL 原生的主從異步復制，Galera 采用的是多主同步復制，并針對同步復制
過程中，會大概率出現的事務沖突和死鎖進行優化，就是復制不基于官方 binlog 而是 Galera
復制插件，重寫了 wsrep api。異步復制中，主庫將數據更新傳播給從庫后立即提交事務，而
不論從庫是否成功讀取或重放數據變化。這種情況下，在主庫事務提交后的短時間內，主從
庫數據并不一致。同步復制時，主庫的單個更新事務需要在所有從庫上同步 更新。換句話
說，當主庫提交事務時，集群中所有節點的數據保持一致。
對于讀操作，從每個節點讀取到的數據都是相同的。對于寫操作，當數據寫入某一節點后，
集群會將其同步到其它節點。
就各個集群方案來說，其優勢為：
1. 多主多活下，可對任一節點進行讀寫操作，就算某個節點掛了，也不影響其它的節點的
讀寫，都不需要做故障切換操作，也不會中斷整個集群對外提供的服務。
2. 拓展性優秀，新增節點會自動拉取在線節點的數據（當有新節點加入時，集群會選擇出
一個 Donor Node 為新節點提供數據），最終集群所有節點數據一致，而不需要手動備份
恢復。
其劣勢為：
能做到數據的強一致性，毫無疑問，也是以犧牲性能為代價。
