為何mysql不用raft等協議實現同步複製？

12-29

首先，Raft論文是2014年才發出來的。其次，mysql本質是一個單機系統，在單機系統的基礎上要高可用，可容錯，最容易想到的方法就是做主備。這和mysql所屬的年代有關。

Basic Paxos根本找不到成功的實現案例，Mutil Paxos適合多點寫入的scale out資料庫。Raft本質上適合scale up資料庫，但是搞這個不太潮，沒什麼技術人願意做。
然而以前沒有，現在有了。
阿里雲RDS的MySQL三節點，基於Raft和semi sync實現，容量最高可達3TB。不想入分散式資料庫坑的同學們可以關注。

MySQL 三節點企業版:https://help.aliyun.com/document_detail/51701.htm?spm=5176.7920929.603378.1.hUuItV

MySQL屬於CA資料庫，也就是說偏重於單機，sharding是由MySql通過手動配置實現來做的，每個分片機的數據各不同，然後MySQL的數據是通過主從方式來實現數據備份，主從跟Quorum voting機制非常不同。
Quorum是一個CP機制，主要解決的問題是在分區系統中保證數據一致性的。這樣像raft這樣的Quorum機制就會假定隨時會存在宕機、分區、組成員變換、數據自由遷移等問題。
主從數據冗餘方式的CA系統基本都是由全局配置來決定的，數據不能隨意存儲遷移，因為MySql的數據索引、查詢等的實現都基於MySql已經規定好的sharding信息等，可以理解為，一旦sharding完成，每個sharding內的數據又變成有一個單機資料庫的思維方式。
一旦MySql引入raft之類的Quorum機制，MySQL的查詢、索引、合併等操作等都需要考慮重新實現了。Raft誕生之初是為了解決日誌同步的一致性問題，從而達到同步數據的結果。這種系統在實現查詢、索引之類的操作時，始終避不開要自上而下建立一套完整和安全的元信息管理driver，來專門實現global的調度、計算、數據遷移以及數據鎖機制等。這跟MySql把這些功能下推的單機版類的資料庫是完全不一樣的構建方式。所以，用不用某一項技術，還是要好好分析構建歷史，以及它們的模型場景。

微信開源了PhxSQL，基於paxos協議的MySQL集群。

主要原因是mysql複製很有歷史了。

皮哥有個大膽的想法:
raft/paxos等分散式協議就干兩件事:1. 選leader 2. 新leader出來後數據如何同步達到一致狀態
a. 選leader交給raft來干。
b. 數據同步到一致狀態交給MySQL原生同步(GTID)來做。
於是一個高可用MySQL集群蛋生鳥。

MySQL是單機資料庫。我們可以使用MySQL構建分散式資料庫。比如 dynamodb。