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 層的麻煩…

Related Posts:

• 從 MySQL (單機) 轉到 Galera Cluster 的前置作業…
• Percona XtraDB Cluster (Galera Cluster) 的教學
• 又有一家大的 MySQL distribution 支援 Galera Cluster…
• Percona 把 Galera Cluster 標為 General Availability 了…
• 看 Mozilla Database Team 的年終報告…