Percona 的 Crash-resistant replication

前幾天 Percona 寫了篇文章說明自家專有的 Crash-resistant replication (用在 Percona Server 5.1 與 5.5):「Crash-resistant replication: How to avoid MySQL replication errors」。

這是 async replication 用在 slave server crash 時的保護機制。

當 slave 更新資料後,會更新 relay log 寫下「目前 apply 到哪個位置」(預設值是 relay-log.info),也就可以依照這個資訊計算出 replication lag 的時間。在 mytop 裡看到的 Delay 欄位就是由此算出來的。

但當 MySQL 寫入後,但 relay-log.info 還沒更新時當掉,會造成下次啟動時重複 apply 同一筆資料。

而 Crash-resistant replication 就是把這個資訊寫到 transaction 內,避免這個問題。

也因此這個功能只有 InnoDB 類的 Engine 才有用,MyISAM 仍然是不受 Crash-resistant replication 保護的。

要打開這個功能也很簡單,只要 my.cnf 設起來就好了,設定說明可以參考原文。

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝),像是這樣的架構:

其中 node{1,2} 為 cluster,node3 則是傳統的 async replication,來源的 master 為 node1。

當 node1 掛掉時,我們沒辦法自動將 node3 的 master 從 node1 改指到 node2,因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值,這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的,就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO,而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後,就有機會寫成程式自動化... 這算是一個不錯的開頭 :p

MySQL 5.6 的 GTID...

看到 Percona 的人在討論 MySQL 5.6 的 GTID (Global Transaction ID) 功能,剛剛就實際到 AWS 上開了兩台 m1.large 測試:「How to create/restore a slave using GTID replication in MySQL 5.6」。

要測試 GTID,因為剛出來沒多久,沒有多少文件可以看。MySQL 官方的「Replication with Global Transaction Identifiers」是必讀的文件。查 MySQL 官方文件時可以發現 5.6.9 (RC) 到 5.6.10 (GA) 其實還是改了不少變數名稱,如果在網路上找舊文章照抄是不會動的...

先提結論,Galera Cluster 畢竟出來很久了,成熟度比 GTID 高,建議現在先觀望一陣子,至少等 best practice 出來後再進場測試...

之前的 MySQL replication 有很多方法可以在不停機,或是停的時間很短的情況下把第一份 slave 資料與 replication 資訊生出來,舉例來說:

  • 系統如果用 InnoDB,可以用 Percona Xtrabackup 拉出。
  • 系統如果用 XFS + LVM,可以用 FLUSH TABLES WITH READ LOCK + XFS freeze + snapshot 功能拉出。
  • 甚至直接用空的 slave 跑 pt-table-sync...

但目前 MySQL 官方對 GTID 給的方式是 read only + mysqldump,這就算用 xtrabackup 也應該快不到哪吧... 這幾個月應該會一直有文章出現,裡面應該會有偷吃步的方法,看到再來測試看看 :o

跳過 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 的設置...