在有些應用場景中，可能讀寫壓力差別比較大，讀壓力特別的大，一個Master可能需要上10臺甚至更多的Slave才能夠支撐注讀的壓力。這時候，Master就會比較吃力了，因為僅僅連上來的SlaveIO執行緒就比較多了，這樣寫的壓力稍微大一點的時候，Master端因為複製就會消耗較多的資源，很容易造成複製的延時。

遇到這種情況如何解決呢？這時候我們就可以利用MySQL可以在Slave端記錄複製所產生變更的BinaryLog資訊的功能，也就是開啟—log-slave-update選項。然後，通過二級（或者是更多級別）複製來減少Master端因為複製所帶來的壓力。也就是說，我們首先通過少數幾臺MySQL從Master來進行復制，這幾臺機器我們姑且稱之為第一級Slave叢集，然後其他的Slave再從第一級Slave叢集來進行復制。從第一級Slave進行復制的Slave，我稱之為第二級Slave叢集。如果有需要，我們可以繼續往下增加更多層次的複製。這樣，我們很容易就控制了每一臺MySQL上面所附屬Slave的數量。這種架構我稱之為Master-Slaves-Slaves架構

這種多層級聯複製的架構，很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風險。下圖展示了多層級聯複製的Replication架構。

當然，如果條件允許，我更傾向於建議大家通過拆分成多個Replication叢集來解決

上述瓶頸問題。畢竟Slave並沒有減少寫的量，所有Slave實際上仍然還是應用了所有的資料變更操作，沒有減少任何寫IO。相反，Slave越多，整個叢集的寫IO總量也就會越多，我們沒有非常明顯的感覺，僅僅只是因為分散到了多臺機器上面，所以不是很容易表現出來。

此外，增加複製的級聯層次，同一個變更傳到最底層的Slave所需要經過的MySQL也會更多，同樣可能造成延時較長的風險。

而如果我們通過分拆叢集的方式來解決的話，可能就會要好很多了，當然，分拆叢集也需要更復雜的技術和更復雜的應用系統架構。