AWS 提供跨區的 MySQL Read Replica...

Amazon RDS 將提供跨區的 MySQL read replication。看起來是針對 5.6+ 的版本提供這個功能...

有兩篇官方文章,一篇是 CTO 發了一篇「Expanding the Cloud: Enabling Globally Distributed Applications and Diaster Recovery」,另外一篇是官方網誌上的「Cross-Region Read Replicas for Amazon RDS for MySQL」。

用圖表示比較容易懂:

在 US-East 建立 MySQL master,另外在 EU 與 Tokyo 建立 slave replication。不知道中間的 traffic 有沒有過 IPSec 或是 SSL?

Galera Cluster 3.x 的設定...

Percona XtraDB Cluster 5.6 用的是 Galera Cluster 3.x 的 patch,所以 Percona 的人寫了一篇介紹 3.x 有哪些設定:「New wsrep_provider_options in Galera 3.x and Percona XtraDB Cluster 5.6」。

看起來來比較有影響的是 gmcast.segment=0,用在跨機房之間的判斷。

看起來應該是同一個機房要設一樣的 gmcast.segment。這個值會用在兩個地方:第一個是跨 segment 的 replication 流量會試著盡可能小。第二個是同步時的 Donor 會優先選擇同機房的節點。

其他的用預設值應該就 okay...

Facebook 發展的 RocksDB...

Facebook 利用 Google 所發展的 LevelDB 開發了 RocksDB,跟 LevelDB 相同,仍然是 persistent key-value store,重點在於能夠使用多個 CPU 增加效能的能力:

RocksDB builds on LevelDB to be scalable to run on servers with many CPU cores, to efficiently use fast storage, to support IO-bound, in-memory and write-once workloads, and to be flexible to allow for innovation.

Performance Benchmarks 這邊可以看到效能的數據,主要都是跟 LevelDB 比較。比較的時候不只是寫了快了多少,而是包含原理都有寫出來。

source code 在 GitHub 上可以翻到:facebook/rocksdb,除了 source code 外,還發現裡面有 PATENTS 這個檔案,裡面針對專利的部份給予豁免... 好像很少看到?

Amazon RDS 支援 PostgreSQL 了...

AWS 的官方公告出來了:「Amazon RDS for PostgreSQL - Now Available」。

而且 AWS 上 MySQL 有的 feature,PostgreSQL 都有:

  • Multi-AZ Deployments
  • Provisioned IOPS
  • Virtual Private Cloud
  • Automated Backups
  • Point-in-time Recovery
  • Cross-Region Snapshot Copy

而且是 PostgreSQL 9.3 (雖然是 9.3.0),如果本來自己用 EC2 搞 PostgreSQL 的都可以切過去了 :p

Percona Server 第一個 5.6 上 GA 版本...

UpdatePercona 自己也寫了一篇「A closer look at Percona Server 5.6」可以參考看看。

Percona 推出 Percona Server 5.6.13-61.0,是 5.6 的第一個 GA 版本:「Percona Server 5.6.13-61.0 first GA release is now available」。

這等好久了,MySQL 官方有給出「What's New in MySQL 5.6」,對我來說其中有幾個亮點需要測試:

效能

至少不能比現在的效能差。

對 memcache protocol 的支援

這是 5.6 的新功能,可以透過 memcache protocol 存取 InnoDB 的資料。如果可行,可以用在 HA memcache protocol 架構。

Time-Delayed Replication

看起來應該很有用,但一時間想不到可以用在哪裡... 應該是 vm 裡面多架幾台 slave 丟著?

Percona 版的修正

Twitter branch 的 Statement Timeout 看起來是個頗有趣的項目?可以想看看用在哪裡...

Overall...

總結來說,測試機測過後,先用在 DBRD + Heartbeat 的系統上 (只換一台,如果發現 5.6 版不好用,可以 downgrade),如果沒問題就再測試 memcache protocol,然後接下來就是等 Percona XtraDB Cluster 也出 5.6 版?

Percona 對 InnoDB 效能的建議...

2007 年的「Innodb Performance Optimization Basics」這篇是以當時的環境寫的 (MySQL 5.0)。過了六年,出了 MySQL 5.1、5.5,目前新版是 5.6。

於是就冒出這篇 2013 年版:「InnoDB performance optimization basics (updated)」。

主要是新的科技與技術讓 InnoDB 有更多選擇可以用。SSD 的發明讓 i/o 效率更好,而檔案系統的改善使得 ext4 開始被大家接受。

另外 InnoDB 自己的改善也能夠充分發揮現代硬體的能力,尤其是對多核心的延展能力。

這篇該講的都有講到,文末雖然打自家廣告推薦 Percona Server with XtraDB,不過這的確是個好東西。

Percona XtraDB Cluster 5.5.33-23-7.6...

Percona XtraDB Cluster (Galera Cluster) 出新版:「Percona XtraDB Cluster 5.5.33-23.7.6 is now available」。

看到了幾個比較特別的功能:

Desync functionality has now been exposed to the client. This can be done either via /*! WSREP_DESYNC */ comment on the query or by setting the global wsrep_desync variable to 1.

這個功能感覺上是打算為了在 Percona Toolkit 裡面配合 pt-table-sync 而準備的?

另外一個重要的功能是限速,這可以避免在伺服器最忙碌的時候加重負擔造成伺服器撐不住:

Percona XtraDB Cluster has implemented new rate limiting, rlimit, option for XtraBackup SST that can be used to avoid saturating the donor node.

以往我是自己 patch 一個 shell script 出來用,現在則變成是原生支援,那麼本來的 patch 方式就要轉換到原生支援上...

然後文末有建議 Debian 使用者在升級前要先安裝 socat,避免升級發生問題 :o

Jeremy Cole 在 XLDB 2013 上的演講:「The MySQL Ecosystem at Scale」

GoogleJeremy ColeXLDB 2013 (Extremely Large Databases) 上的演講投影片:「The MySQL Ecosystem at Scale」(PDF)。

投影片內對於 MySQL 的歷史以及現況的說明的很清楚,另外就是 sharding 那塊的方式很值得看一看,量大之後大家解決的方法都差不多,算是已經被證實可行的方法了。

Amazon RDS 可以直接產生 Read Replica Replication 了...

以往要在 Amazon RDS 產生 Read Replica Replication 需要複雜的 snapshot 處理,但現在 AWS 直接提供這個功能了,而且可以同時生很多台:「New Read Replica Capabilities for Amazon RDS」。

這有多重要呢?以前因應流量瞬間爆增時的方式是增加 web server,並且利用 cache (可能是 memcached) 降低對後端的 query 數量。但因為引入 cache,平常就得處理 cache invalidate 的問題。

而這個方式平常只要處理讀寫分離就可以了。當量爆增時除了 web server 增加,直接增加後端的 RDS server (Read Replica Replication),甚至可以分層:

以目前的步調來看,之後有可能會推出 Master-Master 的 HA 架構?

Update:照 comment 提到的,Multi-AZ 本身就是 HA 架構了...

MySQL InnoDB 與 PostgreSQL 的 Partial Index(es) 是不一樣的東西...

MySQL InnoDB 指的 Partial Index 是:

An index that represents only part of a column value, typically the first N characters (the prefix) of a long VARCHAR value.

PostgreSQL 指的 Partial Indexes 是:

A partial index is an index built over a subset of a table; the subset is defined by a conditional expression (called the predicate of the partial index). The index contains entries only for those table rows that satisfy the predicate. Partial indexes are a specialized feature, but there are several situations in which they are useful.

先講結論,PostgreSQL 可以做掉 MySQL InnoDB 的 Partial Index 想做的事情,而且還更多。

MySQL InnoDB 的 Partial Index 是設定對 prefix index (對字串前面的 n bytes),可能的情況是 CHAR(32) 只對前面 16 bytes 索引。

PostgreSQL 的 Partial Indexes 受益於許多方面而更強大。因為有 Indexes on Expressions,所以除了可以像 MySQL 對 prefix 索引外,也可以索引 suffix,甚至是索引透過 string function 得出來的值。

像是 PostgreSQL 可以設定「我只要索引一月一日出生的人的 username」:

CREATE INDEX test_index ON test_table (username) WHERE birth_month = 1 AND birth_day = 1;

在 MySQL 裡需要反正規化後下 index,或是拆出另外一個表格再下 index 的問題,在善用 PostgreSQL 這些功能就可以省下不少功夫...