一 主從異步複製（MySQL 默認方案）

1. master binlog 實時複製到 slave 的 relay-log 重放
2. 存在延時

3. 優勢

   • 對 master 無影響，支持 master 掛載多個 slave，同時 slave 也可以繼續掛着載 slave（級聯複製）
   • slave 中斷重連可以從記錄的 binlog 最後位置繼續複製

4. 缺點

   • 不是真正的高可用
   • master 掛掉後，可能有 binlog 未複製到 slave 上
   • slave 掛掉需要補齊 binlog 追進度，需要啓動時間，不能立即恢復
   • master 若永久損壞，可能永久丟失數據

二. 主從同步複製

1. 半同步複製：master 需要接受至少一個 slave 消費 binlog 的 ack 才能 commit，master crush 後可能丟數據
2. slave 進度落後導致 master 來不及等待 slave ack 時，master 會切回異步複製，恢復時存在困擾
3. master 寫 binlog 和 slave 寫 binlog 為串行，會增加延時
4. master crash 後需要人工介入重新選主

三. 基於 raft/multi-paxos 複製

代表：Amazon Aurora、阿里 polardb

1. 多副本 binlog 或 redolog，實現實例 crush 後可以快速啓動
2. 可以秒級快速故障恢復
3. 寫入性能仍然受單機 mysql 限制

四. NewSQL 方案

代表：TiDB

1. 重寫 SQL 解析層，轉為 KV 操作，利用 KV 多副本解決高可用
2. 真正意義的分佈式 ACID 數據庫，靈活 scale+高可用
3. 和現有 MySQL 無法 100%兼容
4. 跨庫 join 複雜度高
5. 部署運維複雜度高
6. 目前性能和單機 mysql 有明顯劣勢（最新版本待驗證？）