幹壞事是進步最大的原動力
MySQL replication 通常是資料庫擴充的第一步，因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。
在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar，說明在 MySQL replication 架構下要如何處理讀寫分離。
看起來包括對 replication lag 時的處理 (slave 因為各種原因，導致跟不上 master)，有興趣的人可以去報名聽聽看... 雖然是講 PHP，但這個問題在其他的語言也會遇到，聽觀念也應該有幫助。
「MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。
在文章裡提到，在 5.6.3 之前的版本，MySQL replication 都是 single-threaded，所以當 master 可以充分發揮多 CPU 能力時，slave 仍然要一個更新跑完才會跑下一個更新。
舉例來說，假設 master server 上有兩個 thread 在跑：
UPDATE table1 SET foo = 0 WHERE ...; (SQL 1，假定是 CPU bound，需要跑 100 秒)UPDATE table2 SET bar = 1 WHERE ...; (SQL 2，也假定是 CPU bound，也需要跑 100 秒)假設 thread 1 先執行完，這時候 slave 就會在跑完的時候收到 SQL 1，然後把資料同步進去。等到 100 秒過去後，再跑 SQL 2，再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。
在 master server 執行時會是這樣：
兩個 SQL query 可以同時跑。
到了 slave 時，在 MySQL 5.6.3 之前的 replication 會變成這樣：
可以看到還是得先執行 SQL 1 再執行 SQL 2，所以最長會有 200 秒的 replication lag。
而 5.6.3 之後支援 multi-threaded replication，可以用 slave_parallel_workers 指定平行執行 SQL query 的數量，這讓 master server 與 slave server 之間的 replication lag 降低不少：
在收到同步的 SQL 指令後就可以同時跑，這讓 replication lag 降到 100 秒。
不過還是要提，如果希望把資料同步問題降到最低，那麼 Galera Cluster 可以解的更徹底，不論是寫入的那台 master server，或是其他的 master server (在 Galera Cluster 架構裡都是為 master)，一律都是同步執行：
不會有 master server 與 slave server 不同步的問題，可以減少很多 application 層的麻煩...
前幾天讓人吃驚的新聞，Galera Cluster 離第一次 Percona alpha 測試 (Percona Server 5.1 with Galera replication) 才九個月就進入 GA 了 (相當於九個月內就過完 Beta + RC 階段)：「Announcement of Percona XtraDB Cluster 5.5.20 GA release」。
大家最大的問題還是「這能用嗎」... 不過既然進入 GA 狀態，加上是 Percona，好像可以期待？
Oracle 的公告：「MySQL 5.5 is GA!」，以及 Oracle 的新聞稿：「MySQL 5.5 Now Generally Available」。
MySQL 5.5 比起之前的版本，除了 InnoDB 的改善以外，最重要的是 Semi-Replication 成為內建功能，這個功能使得需要 Read-after-write consistency 的 query 可以不用強制綁在 master 上做...
對於開發者，MySQL 5.5 把本來用的 autotools 換成 CMake 了：「MySQL 5.5: CMake replaces autoconf/automake on all platforms, support for autotools has now been removed」。
接下來就等 Percona 出對應的版本了...
AWS RDS 支援 read replication 了：「Amazon RDS: Announcing Read Replicas」。
不過常見到的問題還是會有，像是 replication lag 以及所產生的 read-after-write 問題。但對於許多 read 需求遠大於 write 需求的應用來說，RDS 新推出的功能可以再簡化 MySQL 的設置...