MySQL主從複製入門
MySQL主從複製入門
首先，我們看一個圖：
影響MySQL-A數據庫的操作，在數據庫執行後，都會寫入本地的日誌系統A中。
假設，實時的將變化了的日誌系統中的數據庫事件操作，在MYSQL-A的3306端口，通過網絡發給MYSQL-B。
MYSQL-B收到後，寫入本地日誌系統B，然後一條條的將數據庫事件在數據庫中完成。那麼，MYSQL-A的變化，MYSQL-B也會變化，這樣就是所謂的MYSQL的複製，即MYSQL replication。
在上面的模型中，MYSQL-A就是主服務器，即master，MYSQL-B就是從服務器，即slave。
日誌系統A，其實它是MYSQL的日誌類型中的二進制日誌，也就是專門用來保存修改數據庫表的所有動作，即bin log。【注意MYSQL會在執行語句之後，釋放鎖之前，寫入二進制日誌，確保事務安全】
日誌系統B，並不是二進制日誌，由於它是從MYSQL-A的二進制日誌複製過來的，並不是自己的數據庫變化產生的，有點接力的感覺，稱爲中繼日誌，即relay log。
可以發現，通過上面的機制，可以保證MYSQL-A和MYSQL-B的數據庫數據一致，但是時間上肯定有延遲，即MYSQL-B的數據是滯後的。
即便不考慮什麼網絡的因素，MYSQL-A的數據庫操作是可以併發的執行的，但是MYSQL-B只能從relay log中讀一條，執行下。因此MYSQL-A的寫操作很頻繁，MYSQL-B很可能跟不上。
主從複製的幾種方式
同步複製
所謂的同步複製，意思是master的變化，必須等待slave-1,slave-2,…,slave-n完成後才能返回。
這樣，顯然不可取，也不是MYSQL複製的默認設置。比如，在WEB前端頁面上，用戶增加了條記錄，需要等待很長時間。
異步複製
如同AJAX請求一樣。master只需要完成自己的數據庫操作即可。至於slaves是否收到二進制日誌，是否完成操作，不用關心。MYSQL的默認設置。
半同步複製
master只保證slaves中的一個操作成功，就返回，其他slave不管。這個功能，是由google爲MYSQL引入的。
主從複製分析
問題1：master的寫操作，slaves被動的進行一樣的操作，保持數據一致性，那麼slave是否可以主動的進行寫操作？
假設slave可以主動的進行寫操作，slave又無法通知master，這樣就導致了master和slave數據不一致了。因此slave不應該進行寫操作，至少是slave上涉及到複製的數據庫不可以寫。實際上，這裏已經揭示了讀寫分離的概念。
問題2：主從複製中，可以有N個slave,可是這些slave又不能進行寫操作，要他們幹嘛？
可以實現數據備份。類似於高可用的功能，一旦master掛了，可以讓slave頂上去，同時slave提升爲master。
異地容災，比如master在北京，地震掛了，那麼在上海的slave還可以繼續。主要用於實現scale out,分擔負載,可以將讀的任務分散到slaves上。
【很可能的情況是，一個系統的讀操作遠遠多於寫操作，因此寫操作發向master，讀操作發向slaves進行操作】
問題3：主從複製中有master,slave1,slave2,…等等這麼多MYSQL數據庫，那比如一個JAVA WEB應用到底應該連接哪個數據庫?
當然，我們在應用程序中可以這樣，insert/delete/update這些更新數據庫的操作，用connection(for master)進行操作，select用connection(for slaves)進行操作。那我們的應用程序還要完成怎麼從slaves選擇一個來執行select，例如簡單的輪循算法。
這樣的話，相當於應用程序完成了SQL語句的路由，而且與MYSQL的主從複製架構非常關聯，一旦master掛了，某些slave掛了，那麼應用程序就要修改了。能不能讓應用程序與MYSQL的主從複製架構沒有什麼太多關係呢？可以看下面的圖：
找一個組件，application program只需要與它打交道，用它來完成MYSQL的代理，實現SQL語句的路由。
mysql proxy並不負責，怎麼從衆多的slaves挑一個？可以交給另一個組件(比如haproxy)來完成。這就是所謂的MYSQL READ WRITE SPLITE，MYSQL的讀寫分離。
問題4：如果mysql proxy , direct , master他們中的某些掛了怎麼辦？
總統一般都會弄個副總統，以防不測。同樣的，可以給這些關鍵的節點來個備份。
問題5：當master的二進制日誌每產生一個事件，都需要發往slave，如果我們有N個slave,那是發N次，還是隻發一次？
如果只發一次，發給了slave-1，那slave-2,slave-3,…它們怎麼辦？
顯然，應該發N次。實際上，在MYSQL master內部，維護N個線程，每一個線程負責將二進制日誌文件發往對應的slave。master既要負責寫操作，還的維護N個線程，負擔會很重。可以這樣，slave-1是master的從，slave-1又是slave-2,slave-3,…的主，同時slave-1不再負責select。slave-1將master的複製線程的負擔，轉移到自己的身上。這就是所謂的多級複製的概念。
問題6：當一個select發往mysql proxy，可能這次由slave-2響應，下次由slave-3響應，這樣的話，就無法利用查詢緩存了。
應該找一個共享式的緩存，比如memcache來解決。將slave-2,slave-3,…這些查詢的結果都緩存至mamcache中。
問題7：隨着應用的日益增長，讀操作很多，我們可以擴展slave，但是如果master滿足不了寫操作了，怎麼辦呢？
scale on ?更好的服務器？ 沒有最好的，只有更好的，太貴了。。。
scale out ? 主從複製架構已經滿足不了。
可以分庫【垂直拆分】，分表【水平拆分】。