如今mysql已經發布了5.6.10，在主從復制功能上做了很多優化，特別是GTID(Global Transaction ID)的引入，
值得再重新寫一篇文章介紹如何配置mysql 5.6.10的主從復制。
還是用mysql::sandbox來測試吧。
主服務器(別名black)安裝在 /home/modify/sandboxes/msb_5_6_10/ 使用5610端口。
從服務器(別名blue)安裝在 /home/modify/sandboxes/msb_5_6_10_a/ 使用5611端口。
第一步，修改配置文件
修改主服務器配置文件my.sandbox.cnf，添加下面的幾行：
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=1
report-port=5610
port=5610
log-bin=black-bin.log
report-host=black
innodb_flush_log_at_trx_commit=1
sync_binlog=1
修改從服務器配置文件，添加下面幾行：
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=2
report-port=5611
port=5611
log-bin=blue-bin.log
report-host=blue
innodb_flush_log_at_trx_commit=1
sync_binlog=1
可以看到主與從的配置文件基本上是相同的，這樣也便於在主服務器掛掉的時候，不用修改配置文件即可把從服務器提升為主。
下面簡單介紹每一行的含義：
binlog-format
采用了row-based， 傳說5.6對row-based replication做了優化，具體不明。
gtid-mode與enforce-gtid-consistency
決定使用gtid。
傳統方式下，主從是基於master binary logfile 與 binary logfile postition的，
當主服務器掛掉，需要把某個從服務器提升為主的時候，需要做很多工作，
主要原因還是在於主從復制其實是異步的，
導致多台從服務器間的數據不一致，有的同步速度快，有的速度慢, 很有可能每一台從服務器上面的Read_Master_Log_Pos都是不同的。
首先要根據Read_Master_Log_Pos來確定每台從服務器缺少binlog中的哪些transactions(evens)，幫它們補充完之後，
從服務器間的數據完全一致了，然後才能把任意一台從服務器提升為主。
這個過程，人工做起來實在是比較痛苦，還好有一些開源的第三方程序可以自動做到，比如MHA。
為了從根本上解決這個問題，gtid(Global Transaction ID)就被開發了出來。
mysql為每一個transactions都生成了獨一無二的ID，由二部分構成：
1) mysql服務器的128bit的UUID
2) 自增的一個int變量。 此服務器的第一個transaction的id就是1，第二個就是2…
比如： 22096C54-FE03-4B44-95E7-BD3C4400AF21:4711
這樣GTID就可以在全局范圍內唯一標識一個transaction。
GTID也會寫入binary log，然後被傳輸到從服務器。
gtid
有了GTID， 主從復制也不再基於master的binary logfile和logfile postition，
從服務器連接到主服務器之後，把自己執行過的GTID(Executed_Gtid_Set) 曾經獲取到的GTID(Retrieved_Gtid_Set)發給主服務器，主服務器把從服務器缺少的GTID及對應的transactions發過去即可。
當主服務器掛掉的時候，可以任意選擇一台從服務器直接提升為主，
然後其它從服務器連接到新的主服務器之後，首先把自已已經執行過的GTID發給新主服務器，
新主根據這些GTID，判斷自己缺少哪些transactions，先把自己補全了(細節不知)，
然後再把從服務器缺少的GTID及對應的transactions發給從服務器，
不過這個過程，只是我的猜測， 下面可以實驗一下，有可能的話，還是要看看mysql的源碼的。
另外，gtid與myisam的關系，也不是很明確。
master-info-repository與relay-log-info-repository
都設置為TABLE， 默認值是FILE, 比如master info就保存在master.info文件中，relay log info保存在relay-log.info文件中，
如果服務器意外關閉，正確的relay info 沒有來得及更新到 relay-log.info文件中，那就比較悲劇了。
如果把它們保存到table: mysql.slave_master_info與 mysql.slave_relay_log_info 中， 這二個table都是innodb類型的， 天生就支持事務，比寫文件靠譜多了。
sync-master-info
If the value of this variable is greater than 0, a replication slave synchronizes its master.info file to disk (using fdatasync()) after every sync_master_info events. 不是很理解。
slave-parallel-workers
5.6以前的從服務器，有一個io線程負責接收binary log，還有一個sql線程負責執行binary log中的sql語句。
如果主服務器的數據更新相當頻繁，而從服務器一般來說硬件性能要低於主服務器，如果只有一個sql線程的話，萬一某條語句執行速度過慢，就卡在這裡了，會導致從服務器落後比較長的時間。
采用多個sql線程，每個sql線程處理不同的database，提高了並發性能，即使某database的某條語句暫時卡住，也不會影響到後續對其它的database進行操作。
ps:如果只有一個database要同步，那麼多個sql線程也沒有什麼意義。
ps2: show slave status裡面的Exec_Master_Log_Pos， 在多個sql線程的情況下，變為 a “low-water” mark，並非表示最近執行到的pos。
