看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決：「MySQL High Availability: Stale Reads and How to Fix Them」，另外在留言也有人提到 Booking.com 的解法：「How Booking.com avoids and deals with replication lag」。
在業務成長到單台 MySQL server 不夠用的情況下，最簡單的擴充方式是架設 slave server，然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split)，但因為 MySQL 的 replication 是非同步的，所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料，也就是 replication lag。
這就大概有幾種作法，一種是當發現 lag 時就回 master 讀，但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看，但這個方法就不保證讀的到東西，因為有可能所有的 slave 都 lag。
以前遇到的時候是拆情境，預設還是 R/W split，但敏感性的資料處理以及金流相關的資料就全部都走 master。
不過文章裡的解法更一般性，在寫入時多寫一份資料，然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...
同樣的想法，其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊，然後在 slave 等待這組 binlog 或 GTID 被執行。
看起來算是很不錯的解法，不知道各家 framework 對這些方式的支援度如何...
