關于MySQL的線上擴容

原文位址：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都是一件不錯的事情。