Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇,裡面提到了 Percona 包的 Galera Cluster,叫 Percona XtraDB Cluster

Percona 算是把 Galera Cluster 包的比較好的 distribution,是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本,叫做 MariaDB Galera Cluster

這篇算是很早期使用 PXC 的人的一些感想:(大概是 2012 年導入,當年雲端也還沒流行,在地端上面自己建,對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的,加上一台沒有資料,這台沒資料的只負責投票組成 quorum,不需要到三台都是大機器,而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入,但實務上會建議都集中在一台寫,這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素,將兩台有資料的機器,一台做 writer,另外一台做 reader 算是常見的架構,然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構,或是後來政治改名為 source-replica 架構),不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題,現在有 GUID 後會好一些)

除了 Galera Cluster 外,另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD:因為 DRBD 可以在兩台機器的 block 層做 mirror,所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純,維護成本也很低,但缺點就是 recovery 的時間會高一些:在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID),而 Galera Cluster 因為等於是 hot-standby,蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上,Galera Cluster 也是因為 hot-standby 大勝:DRBD 這邊的情境等於是 cold start,資料庫內還有很多東西還沒進到 InnoDB buffer,對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西,但後面運作的機制複雜不少 (而且需要有人維護),公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況,讀取速度與 random access 的效率都快很多,這使得 DRBD 切換的成本低很多了,很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定,如果這個時間是可以接受的,用 Galera Cluster 的優點可能就沒那麼高了...

Mobile01 的 Ryan 換 InnoDB 的筆記與心得

沒記錯的話,Mobile01 應該是去年暑假左右從 MyISAM 換成 InnoDB 的?一切的起頭應該是蔣大「現在SSD硬碟可以拿來跑資料庫嗎?」這篇。

另外同場加映,使用 Percona 的工具讓管理上更方便:

MyISAM 是 MySQL 5.0 與 5.1 預設的 storage engine (到 5.5+ 預設的 storage engine 改成 InnoDB),讀取的效能相當好,但總是有些問題。

當時剛好有機會跟蔣大與 Ryan 聊到當時 Mobile01 遇到的問題,問了一些細節後感覺上是 MyISAM 的問題,就提了 MyISAM 與 InnoDB 的優缺點比較,以及幾個 InnoDB 的 High Availability 的解決方案 (晚上就算設備出問題也不用擔心要爬起來救機器):

  • MyISAM 的讀寫互斥、寫入也是互斥。當有資料在讀取時無法更改資料庫內容,而有寫入時其他人不能讀取。另外同時間只能有一個人寫入。(有少數操作是例外,像是 bulk insert,這邊跳過)
  • MyISAM 不是 crash-safe storage engine。機器總是有機會爛掉,這時候除了重開機的時間外,還需要有修 table 的時間,對於網站的 uptime 比較痛。

這兩點是當時 Mobile01 遇到最痛的問題:用 iostat 看起來 I/O 明明就沒有滿,但就是會卡 SQL query,而當機後修資料庫的時間又很長。

一個是已經在業界驗證很久的解決方案 XFS + DRBD + Heartbeat,當機器發生問題時的 downtime 從 30secs 到五分鐘 (依照資料性質與大小而有差異,在切換上線後有資料庫的熱機問題)。

另外一個是當時還很新的 Percona XtraDB Cluster,可以避免資料庫的熱機問題,不過技術很新。

後來 Mobile01 用 RAID 10 的硬體,軟體的部份用 Debian + XFS + DRBD + Heartbeat 跑 Percona Server 的 XtraDB (InnoDB 的加強版),先用 VM 做了 PoC (直接砍掉 mysqld,或是直接關掉 VM 之類的,測試整個機制夠不夠自動化),然後就上線了 :p

記得上線那幾天跟 Ryan 聊,好像效果還不錯吧...

OpenSSL 的 Heartbleed 漏洞不限於 Server,也包含 Client...

Heartbleed 是惡意的 client 可以利用 OpenSSLHeartbeat Extension 漏洞取得 server 的機敏資訊。

而在「Testing for "reverse" Heartbleed」這篇說明 (並且 PoC) 這組漏洞也適用於反向的操作,也就是惡意的 server 可以取得 client 的資訊。

exploit 相較起來比正向的難一些,但還是可行並且成功做出來了。文章裡有描述怎麼實做的...

換句話說,反正手上的 OpenSSL 都趕快升級...

NSA 從兩年前就知道 OpenSSL 的 Heartbleed bug...

依據 Bloomberg 的報導,NSA 兩年前就知道 OpenSSLHeartbleed bug 了:「NSA Said to Exploit Heartbleed Bug for Intelligence for Years」。

翻了 GitHub 上的 mirror 記錄,可以發現是在 2012/01/01 commit 進去的:「commit 4817504d069b4c5082161b02a22116ad75f822b1」,幾乎是一開始就知道了?

苦啊...

OpenSSL 安全漏洞 (CVE-2014-0160)

CVE-2014-0160,又稱 Heartbleed Bug,是 OpenSSL 在 TLS 與 DTLS 協定裡的 Heartbeat Extension (RFC 6520) 的錯誤實作。

OpenSSL 官方的 security advisory 在這:「OpenSSL Security Advisory [07 Apr 2014]」,影響的範圍是:

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.

實務上爆炸的程度則是:

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

比較有描述性的說明可以參考「The Heartbleed Bug」這個站的敘述:

We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

由於 untraceable,這代表我們必須假設所有受影響機器上的 SSL private key 都已經被洩漏出去了,所有的 key 都必須 revoke 並且重新產生 (& 重新簽)。這兩天讓所有 SA 爆炸的超大新聞...

Percona 的 MySQL High Availability 機制比較文

Percona 發了一篇「High-availability options for MySQL, October 2013 update」,比較目前 MySQL 上常見的 High Availability 機制。

包括了五個系統:

  • Percona XtraDB Cluster (PXC)
  • Percona replication manager (PRM)
  • MySQL master HA (MHA)
  • NDB Cluster
  • Shared storage/DRBD

這些都是把 High Availability 做在 MySQL 上,讓前端的程式不需要操心的方式。都是有個固定的 IP address 保證可以讀寫。

這五個方案都不完美,看環境需求而選擇使用。

我一般給的建議還是 Heartbeat + DRBD + InnoDB,這個方法是極為成熟的方法,會遇到的問題網路上都已經討論過了。如果找 Percona 的人支援也是完全沒問題。

Percona XtraDB Cluster 上用 keepalived 實作高可靠度架構

Percona 的人寫了一篇「Using keepalived for HA on top of Percona XtraDB Cluster」,是用 Keepalived 實作高可靠度架構。

目前常見的文章是透過 HAProxy 達成,但 HAProxy 本身就會成為 SPOF,所以一般人的想法就是在 HAProxy 上跑 Keepalived,保持可靠度。但這個問題我之前就抱怨過,既然要跑 Keepalived (我的例子裡是 Heartbeat),為什麼不在 Percona XtraDB Cluster 上跑就好,load balance 的任務則可以透過 DNS round robin 達成:

We would standardly use keepalived to HA HAproxy, and keepalived supports track_scripts that can monitor whatever we want, so why not just monitor PXC directly?

不過我還是偏愛 Heartbeat,因為 Heartbeat 的功能多了一些,不過架構還是很簡單,實際用起來也發現不容易出問題。

另外 Heartbeat 不論是在 Linux 還是 FreeBSD 上都跑得很好,我連內部機器用的 DNS resolver (跑 Unboound) 都上 Heartbeat。

另外也因為 Keepalived 目前不支援 FreeBSD (參考「About "ipvs" and "keepalived"」這篇文章),所以也沒打算花時間測試了... :o

Galera Cluster + Heartbeat

我一向不太喜歡 Galera Cluster + HAProxy 的設計。有四個理由:

  • MySQL server 看不到 client 的 IP。
  • HAProxy 本身就是 SPoF。
  • HAProxy 會增加 latency,並且限制 bandwidth。
  • 通常需要額外的機器跑 HAProxy。

我把跑了超過半年的 Galera Cluster + Heartbeat 的經驗貼到 Codership 的 Group 上,裡面包括了設定與 script,希望能有些迴響:「HA solution - Galera Cluster with Heartbeat」。