看到今年的 SIGMOD17 上 Amazon 有一篇關(guān)于 Amazon Aurora 的 paper, 趕緊在周末的時候讀了一下, 說不定哪天就 Aurora 就作為存儲選型的一個 option 了, 要準(zhǔn)備一下. 寫點兒筆記
0x00 準(zhǔn)備知識
這篇 paper 主要是關(guān)于 Aurora 如何將 MySQL 的 redo log 獨(dú)立設(shè)計成一個存儲服務(wù), 從而提高了 Aurora 的吞吐的. 那么 MySQL 的 redo log 到底是什么?
redo log 就是 MySQL 的 WAL log, 是為了確保事務(wù)的持久性的. 每次事務(wù)提交前都需要確保 redo log 被持久化. 當(dāng)數(shù)據(jù)庫 crash 時, 會使用 redo log 進(jìn)行 point-in-time recovery
需要注意的是: MySQL 中還有一個 binlog. redo log 和 binlog 不是一回事:
- binlog 是針對 MySQL 所有的引擎, 主要用來主從復(fù)制, 有
ROW和STATEMENT兩種格式 - redo log 僅僅存在于 InnoDB 引擎, 用于記錄每個頁的改動情況.
從數(shù)據(jù)庫架構(gòu)上來說, 僅僅是將下圖中的 Log Manager 中的一部分功能剝離出 MySQL, 做成一個高可用的服務(wù), 其他部分不變.
0x01 為何要剝離 redo log
在存儲和計算分離的大趨勢下, 大家都是玩兒集群, 因此系統(tǒng)的瓶頸從之前的磁盤, 到現(xiàn)在變成了網(wǎng)絡(luò) IO. 如圖常規(guī)情況下的 MySQL 集群網(wǎng)絡(luò) IO, 在 AWS 中一個常規(guī)使用 EBS 的主從 MySQL 集群, 網(wǎng)絡(luò) IO 是這樣的:
獨(dú)立出 redo log 服務(wù)后的 Aurora 集群, 網(wǎng)絡(luò) IO 是這樣的:
也就是說 Aurora 僅僅需要把一個 Quorum 中的日志寫成功就可以. 這種架構(gòu)也有一個缺點: 放大了 replication 的 IO. 之前寫 binlog 到 replica, 現(xiàn)在要寫 redo log.
這么做的好處有3點:
- 將存儲服務(wù)做成一個跨數(shù)據(jù)中心的服務(wù), 提高數(shù)據(jù)庫容災(zāi), 降低性能影響
- 大幅度將低網(wǎng)絡(luò) IO, 為其他優(yōu)化騰出了空間
- 之前備份等操作都很 expensive, 現(xiàn)在在單獨(dú)的存儲服務(wù)上, 都不是事兒
文中給了一個網(wǎng)絡(luò) IO 對比的數(shù)據(jù):
Table 1: Network IOs for Aurora vs MySQL
| Configuration | Transactions | IOs/Transaction |
|---|---|---|
| Mirrored MySQL | 780,000 | 7.4 |
| Aurora with Replicas | 27,378,000 | 0.95 |
0x02 durability at scale: 規(guī)睦缯郑化的 durability
如何確保數(shù)據(jù)的 durablity? 多寫幾份唄. 基于 Quorum 機(jī)制, 常規(guī)來說僅僅需要滿足如下公式:
- Vr + Vw > V
- Vw > V/2
而且一般情況下, 大家都是選擇 V=3, Vr = 2, Vw=2 (也就是說數(shù)據(jù)存儲3份: 寫入2份成功才算成功, 讀取2份成功才算成功).
但 Aurora 認(rèn)為使用3個AZ(AZ 就是 AWS 的機(jī)房的概念)每個 AZ 一份數(shù)據(jù)的情況不靠譜, 因此選擇3個 AZ 存儲 6 分?jǐn)?shù)據(jù): 每個 AZ 2份:
- V = 6
- Vw = 4
- Vr = 3
這樣能夠保證一個機(jī)房故障, 并且剩余兩個機(jī)房有一個節(jié)點故障的情況下可用.
為了提高 MTTR(Mean Time To Repair) 時間, 還把存儲每10 GB 作為 Protection Group, 自我修復(fù), 提高修復(fù)時間.
0x03 存儲服務(wù)設(shè)計
說到存儲服務(wù)的設(shè)計, 核心的原則就是 latency 一定要低. 把能異步做的事情都異步都后臺做, 數(shù)據(jù)一旦落地立即返回. 如圖:
- LOG 請求進(jìn)來, 落地就從
2返回, 盡最大可能降低 latency -
4是通過 Gossip 協(xié)議, 與其他 peer 通信, 修復(fù)數(shù)據(jù)
0x04 Aurora 性能
我也沒有實際用過 Aurora, 貼一張 paper 中的數(shù)據(jù)吧
0x05 疑問
關(guān)于 binlog
看完 Aurora 的設(shè)計, 有一點疑惑的是, 主從復(fù)制使用了 redo log, 那么原生的 binlog 在 Aurora 中是否還存在? 找了一下文檔, 發(fā)現(xiàn) binlog 還是在的, 參見 Replication Between Aurora and MySQL or Between Aurora and Another Aurora DB Cluster
關(guān)于 MySQL 新 feature
另外一個疑惑就是關(guān)于 MySQL 新版本的 feature. 如果 MySQL 社區(qū)版本推出了一個新的 feature, Aurora 何時能夠跟進(jìn)并提供相應(yīng)的功能(比如 JSON 字段類型)? 其實 Aurora 到底是基于哪個版本的 MySQL 的 source code 構(gòu)建的, 我們也不得而知.
0x06 總結(jié)
存儲計算分離, 連 OLTP 的數(shù)據(jù)庫都在按照這個思路拆. Aurora 不僅僅止步于 MySQL, 去年的 re:Invent 2016 上發(fā)布了 Aurora 兼容 PostgreSQL 的版本. 至于 Aurora 怎么評價, 可以摘一句 Percona co-founder 的一句:
In general I think Amazon Aurora is a quite advanced proprietary version of MySQL. It is not revolutionary, however, and indeed not “reimagined relational databases” as Amazon presents it. This technology does not address a problem with scaling writes, sharding and does not handle cross-nodes transactions.
-- by Vadim Tkachenko
我個人倒是覺得, 反正我也不去寫數(shù)據(jù)庫(我也不會寫), 是否 re-invent 數(shù)據(jù)庫我不管, 能夠讓我不用分庫分表, 價格還讓我老板滿意我就開心.
Reference
- MySQL · 引擎特性 · InnoDB redo log漫游
- Amazon Aurora – Looking Deeper
- 阿里云、Amazon溅蛉、Google云數(shù)據(jù)庫方案架構(gòu)與技術(shù)分析
-- EOF --
