跳過 MySQL replication 失敗的方法...

MySQL replication 發生錯誤後,需要一邊 skip replication error,一邊跑 pt-table-sync 強制資料庫同步:

while true; do ( echo 'SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;' | mysql -h $1 ) || sleep 1; done

那個 sleep 1 的設計是用在「如果 replication 正常,停一下再跑一次」的前提下而設計的;如果不需要的話拿掉也是 okay 的。

要注意,能這樣跑的前提是 max_connect_errors 要開超大,我是設成 max_connect_errors = 4294967295

Stripe 發表了將 MongoDB 資料倒到 PostgreSQL 的工具:MoSQL

Stripe 是家電子付款的新創公司,相較於既有的電子付款機制 (像是 PayPal),Stripe 所提供的工具與介面對開發者與使用者非常友善。

昨天 Stripe 推出了即時將 MongoDB 的資料倒到 PostgreSQL 的工具 MoSQL:「Announcing MoSQL」。

據官方說法,要撈資料的時候用 SQL 比較方便,而且每個人都懂 SQL,所以他們開發了 MoSQL:

The thing is, we also love SQL. We love the ease of doing ad-hoc data analysis over small-to-mid-size datasets in SQL. We love doing JOINs to pull together reports summarizing properties across multiple datasets. We love the fact that virtually every employee we hire already knows SQL and is comfortable using it to ask and answer questions about data.

由於 PostgreSQL 9.2 支援 JSON 資料結構,感覺很像是要逃離 MongoDB 的工具啊... 雖然官方都不承認 XD

Percona 將辦 Webinar 說明資料庫讀寫分離時的處理...

MySQL replication 通常是資料庫擴充的第一步,因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。

在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar,說明在 MySQL replication 架構下要如何處理讀寫分離。

看起來包括對 replication lag 時的處理 (slave 因為各種原因,導致跟不上 master),有興趣的人可以去報名聽聽看... 雖然是講 PHP,但這個問題在其他的語言也會遇到,聽觀念也應該有幫助。

MySQL 平行執行的 Replication...

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 在跑:

  • thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1,假定是 CPU bound,需要跑 100 秒)
  • thread 2 正在執行 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 層的麻煩...

Percona 把 Galera Cluster 標為 General Availability 了...

前幾天讓人吃驚的新聞,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,好像可以期待?

MySQL 5.5 GA (General Availibility)!

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

AWS RDS 支援 read replication 了:「Amazon RDS: Announcing Read Replicas」。

不過常見到的問題還是會有,像是 replication lag 以及所產生的 read-after-write 問題。但對於許多 read 需求遠大於 write 需求的應用來說,RDS 新推出的功能可以再簡化 MySQL 的設置...