根據業務需要，建立MySQL復制來實現數據冗余。
MySQL 5.6.10版本提供了更方便的基於GTID的復制功能，MySQL可以通過GTID自動識別上次同步的點，極大地方便了運維人員，減少出錯的幾率。
在官方文檔中提到，最保險可靠的復制方式，是基於row的復制，所以寧可犧牲一些性能也要保證數據的安全。
現實環境中，master主數據庫MySQL 5.6.10(msi安裝方式)安裝在Windows 2008 Server x64上，slave從服務器是一台老舊的DELL服務器，運行CentOS 6.4 x64系統，源碼編譯安裝MySQL 5.6.10的Linux版本，安裝過程可以參考我以前的博文：http://www.cnblogs.com/jlzhou/archive/2013/03/09/2951544.html
不同平台下，MySQL是有一些差異的，要小心處理。
第一個問題是，Windows平台下，文件名大小寫不敏感，造成對應的MySQL的數據表名稱默認都采用小寫字母方式，同時大小不寫敏感，參考我以前的博文：http://www.cnblogs.com/jlzhou/archive/2013/03/18/2966106.html 為了能將數據同步復制到Linux平台的MySQL，我們需要設置Linux平台下MySQL的數據表名稱設置：(修改my.cnf文件)
[mysqld] lower_case_table_names=1
第二個問題是，自增字段0值的問題。因為現有數據庫是MSSQL，業務邏輯需要某些表的自增字段從0開始。參考我以前的博文：http://www.cnblogs.com/jlzhou/archive/2013/03/18/2965384.html 為了在Windows平台和Linux平台的MySQL之間復制數據，增加全局變量設置，在my.ini和my.cnf中分別添加NO_AUTO_VALUE_ON_ZERO設置到sql-mode行：
//my.ini 該文件默認在Windows7或Windows2008操作系統中位於 C:\ProgramData\MySQL\MySQL Server 5.6 目錄下（采用MSI安裝方式），如果你自定義了數據目錄，則該配置文件在數據目錄下。
# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,NO_AUTO_VALUE_ON_ZERO"
現在開始配置GTID復制，先配置master端的my.ini文件，加入下述配置，然后重啟master的MySQL服務：
binlog-format=ROW log-bin=master-bin.log log-bin-index=master-bin.index log-slave-updates=true gtid-mode=on enforce-gtid-consistency=true 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 sync_binlog=1
再修改slave端的my.cnf文件，加入下述配置，然后重啟slave的MySQL服務：
binlog-format=ROW log-bin=slave-bin.log log-bin-index=slave-bin.index log-slave-updates=true gtid-mode=on enforce-gtid-consistency=true 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 sync_binlog=1
其實，並不需要在slave端啟用binlog，但是為了在master故障時，方便的轉換slave到master，並且方便建立slave的slave，所以采用和主服務器類似的配置。
復制設置會將用於復制的用戶和密碼以明文形式保存在master.info文件中，最好為復制建立專用的用戶，授予 REPLICATION SLAVE 權限。
在master端執行：
GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.1.101' IDENTIFIED BY '12345678';
最后，在slave執行指向master的命令，並開啟slave復制。
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_PORT=3306, MASTER_USER='repluser',MASTER_PASSWORD='12345678', master_auto_position=1;
START slave;
這時就可以測試在master上建立數據庫，建表，然后監控slave的復制狀態了。
本文中沒有涉及到已有數據庫在master上的情況，請參考這篇博文：http://www.zhaokunyao.com/archives/4131
后記：
附上備份和恢復腳本：命令行執行
Backup from remote server scripts: // for test database: "C:\MySQL\MySQL Server 5.6\bin\mysqldump.exe" --user=root --max_allowed_packet=1G --host=10.192.8.105 --port=3306 --default-character-set=utf8 --set-gtid-purged=OFF --password --databases test > "C:\\Backup\\test.dump.sql" Restore to local dev machine scripts: // for test database: "C:\MySQL\MySQL Server 5.6\bin\mysql.exe" --host=localhost --user=root --port=3306 --password --default-character-set=utf8 --comments < "C:\\Backup\\test.dump.sql"
注意，上述腳本中，備份的部分要加入--set-gtid-purged=OFF參數，防止在備份出的sql腳本中生成 SET @@global.gtid_purged 語句：
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF.
官方文檔關於set-gtid-purged是這樣寫的：
This option enables control over global transaction ID (GTID) information written to the dump file, by indicating whether to add a SET @@global.gtid_purged statement to the output.