原文地址：http://bucketli.iteye.com/blog/1294032
主要簡單總結下，mysql在線擴容和縮容一般涉及到的內容，主要包括三個方面，1.在線也就意味着需要把增量的數據重新分布到新的拓撲結構中,我們一般稱做增量復制，2.原有的數據需要一條不漏的掃出來重新分布到新的拓撲結構中,這個一般叫做全量復制，3.全量做完，增量正在同步，把應用的數據路由拓撲切到新的路由拓撲上來，並且做到無數據丟失，這個我們叫做停寫切換。做好這三個方面的工作，能夠達到的效果就是應用在最后切換數據分布拓撲的時刻，只要停寫非常短的時間(秒級別)就能夠做到無數據丟失的擴容和縮容。
增量同步一般有2種方式，一種是應用端或者數據庫前端做trigger,記錄變更數據的特征值log(比如pk,sharding key)，然后異步復制到新的拓撲結構中。另外一種方式是通過分析mysql的binlog再進行不同數據拓撲的復制。兩者本質上來說應該是一樣的，后者可能更加簡便，並且對應用無侵入，前者雖然也能夠做到，實際實現或者推廣和操作上都有不少阻力，最起碼解析binlog方式是mysql一上去，更新的log已經天然存在與binlog中了。
增量同步的兩種方式如果要考慮到同步的可伸縮性(也就是多台機器可以同時消費相同的變更日志)，需要在原數據中添加數據的版本信息防止更新亂序，或者通過唯一鍵進行復制機器的sharding,也就是不同進程(線程)同時消費相同的更新日志，必須讓同一條記錄的更新落在同一個線程里面，如果還需要保證復制的事務，那么實現會非常復雜，一般不會去支持多線程下復制的事務。
全量復制，也就是掃描需要復制的表的數據進行重新分布，主要存在的問題是復制速度和對數據庫的寫入壓力的矛盾，其實能夠做到整個拓撲連數據庫都全部換掉，來達到對正在使用數據庫的0影響，這個是一種可行的方案，另外是分時段調整復制線程數，一般單線程復制對於數據庫的影響不會很大，在凌晨再轉換成多線程方式達到提速的目標。
擴容或者縮容在最后階段如何切換，這個涉及到的問題主要是如何避免新更新進來以至於增量沒完沒了，方式有很多，最簡單的方法就是停掉應用，一般時間只有幾分鍾是可以接受的。另外一種是邏輯停寫，因為我們遷移的時候是有一個規則去重新散列數據，也就是如果新的規則和舊的規則兩者算出來的結果不一致，那么這個數據就是需要被遷移的，如果在停寫的時刻，向前端拋錯即可。邏輯停寫最大的好處就是避免PE的介入，並且配合動態的數據路由數據推送，可以完全避免重新發布達到擴容或者縮容，這個就是真正的在線擴容，停寫不可避免（等待延遲的增量同步完成），但是不影響讀。
數據擴容或者縮容，我們覺得不應該排入業務的開發日程中，而是由數據管理團隊對應用透明地進行這種操作，最后介入的人員只是DBA而已。但是不像一些nosql一樣按容量或者完全透明的split,數據庫的sharding還是按照應用的數據特性（pk,user_id,gmt_create等等不同字段，自選策略）進行sharding,應用知道他們的某條數據具體存在哪個機器哪張表上，這個無論對於開發還是測試或者DBA都是一件不錯的事情。