MySQL集羣（一）之主從複製
mysql集羣技術：主從複製，讀寫分離
relay 傳遞
Slave 複數、奴隸
replication 複製
privileges 特權
主從複製，只能有一個主節點，可以用n多個從節點
一、配置文件
在執行這個主從複製之前，首先必須打開 Master 端的Binary Log(MySQL-bin.xxxxxx)功能，否則無法實現。從服務器也需要開啓二進制日誌和 relay 日誌功能 .這樣可以從主服務器讀取 binlog, 併產生 relaylog。
在啓動 MySQL Server 的過程中使用“log-bin” 參數選項
在 my.cnf 配置文件中的 MySQLd 參數組中增加“log-bin” 參數項
一般Linux中的MySQL配置文件都在/etc/my.cnf (windows中的配置文件爲mysql.ini)
log-bin=mysql-bin 開啓二進制日誌
注意：二進制日誌必須開啓，因爲數據的同步實質上就是其他的MySQL數據庫服務器將這個數據變更的二進制日誌在本機上再執行一遍。
二、Mysql主從複製的原理
1、主服務器凡運行語句 , 都產生一個二進制日誌 binlog
2、從服務器不斷讀取主服務器的 binlog
3、從主服務讀取到的 binlog, 轉換爲自身可執行的 relaylog,
4、執行 relaylog
實現步驟 :
1、首先確保主服務器打開二進制日誌功能 ,這樣主服務器一旦有數據變化 ,立即產生二進制日誌
2、從服務器也需要開啓二進制日誌和 relay 日誌功能 ,這樣可以從主服務器讀取 binlog, 併產生 relaylog
3、在主服務器建立一個從服務器的賬號 , 並授予各種數據庫權限。指定從服務對應的主服務器 , 開啓從服務器 .
三、Mysql主從複製的過程
3.1、主從複製詳細過程
MySQL 的 Replication 是一個異步的複製過程，在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成，其中兩個線程(Sql 線程和IO 線程)在 Slave 端，另外一個線程(IO 線程)在 Master 端。
1） Slave 上面的IO 線程連接上 Master，並請求從指定日誌文件的指定位置(或者從最開始的日誌)之後的日誌內容。
2） Master 接收到來自 Slave 的 IO 線程的請求後，通過負責複製的 IO 線程根據請求信息讀取指定日誌指定位置之後的日誌信息，返回給 Slave 端的 IO 線程。
返回信息中除了日誌所包含的信息之外，還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 BinaryLog 中的位置。
3）Slave 的 IO 線程接收到信息後，將接收到的日誌內容依次寫入到 Slave 端的RelayLog （中繼日誌文件）文件(MySQL-relay-bin.xxxxxx)的最末端，並將讀取到的Master 端的bin-log 的文件名和位置記錄到master-info 文件中，以便在下一次讀取的時候能夠清楚的告訴Master “我需要從某個bin-log 的哪個位置開始往後的日誌內容，請發給我” 。
4）Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容後，會馬上解析該 Log 文件中的內容爲在 Master 端真實執行的那些可執行的 Query 語句，並在自身執行這些 Query。
這樣，實際上就是在 Master 端和 Slave 端執行了同樣的 Query，所以兩端的數據是完全一樣的。
3.2、Mysql主從複製過程的圖形表示
四、MySQL支持的複製類型與MySQL複製應用類型
4.1、MySQL支持的複製類型
1）基於語句的複製statement： 在主服務器上執行的SQL語句，在從服務器上執行同樣的語句。MySQL默認採用基於語句的複製，效率比較高。一旦發現沒法精確複製時，會自動選着基於行的複製。
2）基於行的複製row：把改變的內容複製過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
3）混合類型的複製mixed: 默認採用基於語句的複製，一旦發現基於語句的無法精確的複製時，就會採用基於行的複製。
4.2、MySQL複製應用類型
1）數據分佈 (Data distribution )
2）負載平衡(load balancing)
3）讀寫分離(split reading and writting)
4）高可用性和容錯性 (High availability and failover )
5、哪些原因會導致mysql主從數據不一致
1.網絡的延遲
由於mysql主從複製是基於binlog的一種異步複製，通過網絡傳送binlog文件，理所當然網絡延遲是主從不同步的絕大多數的原因，特別是跨機房的數據同步出現這種機率非常的大，所以做讀寫分離，注意從業務層進行前期設計。
2.主從兩臺機器的負載不一致
由於mysql主從複製是主數據庫上面啓動1個io線程，而從上面啓動1個sql線程和1個io線程，當中任何一臺機器的負載很高，忙不過來，導致其中的任何一個線程出現資源不足，都將出現主從不一致的情況。
3.max_allowed_packet設置不一致
主數據庫上面設置的max_allowed_packet比從數據庫大，當一個大的sql語句，能在主數據庫上面執行完畢，從數據庫上面設置過小，無法執行，導致的主從不一致。
4.mysql異常宕機情況下，如果未設置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出現binlog或者relaylog文件出現損壞，導致主從不一致。
MySQL提供一個sync_binlog參數來控制數據庫的binlog刷到磁盤上去。
默認sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系統自己控制它的緩存的刷新。這時候的性能是最好的，但是風險也是最大的。因爲一旦系統Crash，在binlog_cache中的所有binlog信息都會被丟失。
如果sync_binlog>0，表示每sync_binlog次事務提交，MySQL調用文件系統的刷新操作將緩存刷下去。最安全的就是sync_binlog=1了，表示每次事務提交，MySQL都會把binlog刷下去，是最安全但是性能損耗最大的設置。這樣的話，在數據庫所在的主機操作系統損壞或者突然掉電的情況下，系統纔有可能丟失1個事務的數據。但是binlog雖然是順序IO，但是設置sync_binlog=1，多個事務同時提交，同樣很大的影響MySQL和IO性能。雖然可以通過group commit的補丁緩解，但是刷新的頻率過高對IO的影響也非常大。對於高併發事務的系統來說，“sync_binlog”設置爲0和設置爲1的系統寫入性能差距可能高達5倍甚至更多。
所以很多MySQL DBA設置的sync_binlog並不是最安全的1，而是100或者是0。這樣犧牲一定的一致性，可以獲得更高的併發和性能。
5.key自增鍵開始的鍵值跟自增步長設置不一致引起的主從不一致。
6.mysql本身的bug引起的主從不同步。
7.版本不一致，特別是高版本是主，低版本爲從的情況下，主數據庫上面支持的功能，從數據庫上面不支持該功能。