1：配置非同步複製
scripts/mysql_install_db --user=mysql --datadir=/mysql/data
bin/mysqld_safe --user=mysql &

在master上建立複製使用者：
mysql> GRANT replication slave ON *.* TO 'repl'@'%' identified by 'oracle';
mysql> flush privileges;

在slave上：
change master to master_host='192.168.1.23',
 master_port=3306, master_user='repl', 
master_password='oracle', master_log_file='mysql3306-bin.000003',master_log_pos=120;

start slave;

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.23
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql3306-bin.000003
          Read_Master_Log_Pos: 397
               Relay_Log_File: mysql3306-relay-bin.000002
                Relay_Log_Pos: 564
        Relay_Master_Log_File: mysql3306-bin.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
看到兩個yes，完成主從配置


2：半同步複製的安裝部署
要想使用半同步複製，必須滿足以下幾個條件：
MySQL 5.5及以上版本，變數have_dynamic_loading為YES，非同步複製已經存在

首先載入外掛：
因使用者需執行INSTALL PLUGIN, SET GLOBAL, STOP SLAVE和START SLAVE操作，所以使用者需有SUPER許可權。

主：
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

從：
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

檢視外掛是否載入成功
有兩種方式：
a： 
mysql> show plugins;
......
| rpl_semi_sync_master       | ACTIVE   | REPLICATION        | semisync_master.so | GPL     |
+----------------------------+----------+--------------------+--------------------+---------+

b：在master
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS  WHERE PLUGIN_NAME LIKE '%semi%';
+----------------------+---------------+
| PLUGIN_NAME          | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE        |
+----------------------+---------------+
 
在slave :
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS  WHERE PLUGIN_NAME LIKE '%semi%';
+---------------------+---------------+
| PLUGIN_NAME         | PLUGIN_STATUS |
+---------------------+---------------+
| rpl_semi_sync_slave | ACTIVE        |
+---------------------+---------------+

啟動半同步複製：
在安裝完外掛後，半同步複製預設是關閉的，這時需設定引數來開啟半同步
master：
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;

slave：
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;

重啟slave的IO執行緒：
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

如果沒有重啟，則預設還是非同步複製，重啟後，slave會在master上註冊為半同步複製的slave角色。

這時候，master的error.log中會列印如下資訊：
2016-08-26 07:35:25 6939 [Note] Semi-sync replication initialized for transactions.
2016-08-26 07:35:25 6939 [Note] Semi-sync replication enabled on the master.
2016-08-26 07:36:41 6939 [Note] Stop asynchronous binlog_dump to slave (server_id: 243306)
2016-08-26 07:36:41 6939 [Note] Start semi-sync binlog_dump to slave (server_id: 243306), pos(mysql3306-bin.000003, 397) 

檢視半同步是否在執行：
主：
mysql> show status like 'Rpl_semi_sync_master_status';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | ON    |
+-----------------------------+-------+

從：
mysql> show status like 'Rpl_semi_sync_slave_status';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Rpl_semi_sync_slave_status | ON    |
+----------------------------+-------+
這兩個變數常用來監控主從是否執行在半同步複製模式下。

至此，MySQL半同步複製搭建完畢~

#########################################

一、簡介
pt-table-checksum是percona-toolkit系列工具中的一個， 可以用來檢測主、 從資料庫中資料的一致性。
其原理是在主庫上執行， 對同步的表進行checksum， 記錄下來。 然後對比主從中各個表的checksum是否一致， 
從而判斷資料是否一致。檢測過程中以塊為單位， 對於大的表可以區分為多個塊， 從而避免鎖表（ 根據唯一
索引將表切分為塊）檢測時會自動判斷複製延遲、 master的負載， 超過閥值後會自動將檢測暫停。

pt-table-sync，顧名思義，用來修復多個例項之間資料的不一致。它可以讓主從的資料修復到最終一致，
也可以使通過應用雙寫或多寫的多個不相關的資料庫例項修復到一致。同時它還內部集成了pt-table-checksum的校驗功能，
可以一邊校驗一邊修復，也可以基於pt-table-checksum的計算結果來進行修復。

二、工作原理
1. 單行資料checksum值的計算
計算邏輯與pt-table-checksum一樣，也是先檢查表結構，並獲取每一列的資料型別，把所有資料型別都轉化為字串，
然後用concat_ws()函式進行連線，由此計算出該行的checksum值。checksum預設採用crc32計算。

2. 資料塊checksum值的計算
同pt-table-checksum工具一樣，pt-table-sync會智慧分析表上的索引，然後把表的資料split成若干個chunk，
計算的時候以chunk為單位。可以理解為把chunk內所有行的資料拼接起來，再計算crc32的值，即得到該chunk的checksum值。

3. 壞塊檢測和修復
前面兩步，pt-table-sync與pt-table-checksum的演算法和原理一樣。再往下，就開始有所不同：
pt-table-checksum只是校驗，所以它把checksum結果儲存到統計表，然後把執行過的sql語句記錄到binlog中，任務就算完成。語句級的複製把計算邏輯傳遞到從庫，並在從庫執行相同的計算。pt-table-checksum的演算法本身並不在意從庫的延遲，延遲多少都一樣計算(有同事對此不理解，可以參考我的前一篇文章)，不會影響計算結果的正確性(但是我們還是會檢測延遲，因為延遲太多會影響業務，所以總是要加上—max-lag來限流)。 

pt-table-sync則不同。它首先要完成chunk的checksum值的計算，一旦發現主從上同樣的chunk的checksum值不同，
就深入到該chunk內部，逐行比較並修復有問題的行。其計算邏輯描述如下(以修復主從結構的資料不一致為例，
業務雙寫的情況修復起來更復雜—因為涉及到衝突解決和基準選擇的問題，限於篇幅，這裡不介紹)：

對每一個從庫，每一個表，迴圈進行如下校驗和修復過程。對每一個chunk，在校驗時加上for update鎖。
一旦獲得鎖，就記錄下當前主庫的show master status值。

在從庫上執行select master_pos_wait()函式，等待從庫sql執行緒執行到show master status得到的位置。
以此保證，主從上關於這個chunk的內容均不再改變。

對這個chunk執行checksum，然後與主庫的checksum進行比較。
如果checksum相同，說明主從資料一致，就繼續下一個chunk。
如果checksum不同，說明該chunk有不一致。深入chunk內部，逐行計算checksum並比較(單行的checksum的比較過程
與chunk的比較過程一樣，單行實際是chunk的size為1的特例)。

如果發現某行不一致，則標記下來。繼續檢測剩餘行，直到這個chunk結束。

對找到的主從不一致的行，採用replace into語句，在主庫執行一遍以生成該行全量的binlog，並同步到從庫，
這會以主庫資料為基準來修復從庫；對於主庫有的行而從庫沒有的行，採用replace在主庫上插入(必須不能是insert)；
對於從庫有而主庫沒有的行，通過在主庫執行delete來刪除(pt-table-sync強烈建議所有的資料修復都只在主庫進行，
而不建議直接修改從庫資料；但是也有特例，後面會講到)。

直到修復該chunk所有不一致的行。繼續檢查和修復下一個chunk。
直到這個從庫上所有的表修復結束。開始修復下一個從庫。

三、校驗測試
1：測試環境
Mysql Version ： 5.6.28
OS Version ： CentOS release 6.5 
Master IP : 192.168.1.23
Slave  IP : 192.168.1.24

2.Master伺服器安裝Yum依賴包：
yum install perl perl-devel perl-Time-HiRes perl-DBI perl-DBD-MySQL

3.安裝percona-toolkit工具包
wget http://www.percona.com/get/percona-toolkit.tar.gz
tar zxf percona-toolkit-2.2.13.tar.gz
cd percona-toolkit-2.2.13
perl Makefile.PL
make && make install

4.Master / Slave 資料庫建立使用者及授權
create database pt CHARACTER SET utf8;
GRANT UPDATE,INSERT,DELETE,SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO ‘checksums‘@'%' identified by 'oracle';
GRANT ALL ON pt.* TO 'checksums'@'%' IDENTIFIED BY 'oracle';

use pt;
CREATE TABLE IF NOT EXISTS checksums (
db char(64) NOT NULL,
tbl char(64) NOT NULL,
chunk int NOT NULL,
chunk_time float NULL,
chunk_index varchar(200) NULL,
lower_boundary text NULL,
upper_boundary text NULL,
this_crc char(40) NOT NULL,
this_cnt int NOT NULL,
master_crc char(40) NULL,
master_cnt int NULL,
ts timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (db, tbl, chunk),
INDEX ts_db_tbl (ts, db, tbl)
) ENGINE=InnoDB;

5.校驗（Master伺服器執行）
pt-table-checksum --nocheck-binlog-format --nocheck-plan --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --databases test -u'checksums' -p'oracle' -h192.168.1.23

#-h -u -p -P -S -d 連線資訊
#--nocheck-replication-filters 檢測中忽略mysql 配置引數binlog_ignore_db等。
#--nocheck-binlog-format 不檢測日誌格式
#--replicate 指定checksum 儲存的db和表， 如test.checksum
# --chunk-size， --chunk-size-limit 用於指定檢測塊的大小。 可控性更強
# --ignore-databases/tables/column 跳出指定元素的過濾
# --lock-wait-timeout innodb 鎖的超時設定， 預設為1
# --max-load 設定最大併發連線數
# --replicate-check-only 只輸出資料不一致的資訊。
# --help 有這個就行了， 以及其他的詳見文件。
備註：--no-check-binlog-format 忽略檢查binlog格式，否則會報錯，預設會去檢查statement模式，一般我們都用row模式


結果說明：
TS ：完成檢查的時間。
ERRORS ：檢查時候發生錯誤和警告的數量。
DIFFS ：0表示一致，1表示不一致。當指定--no-replicate-check時，會一直為0，當指定--replicate-check-only會顯示不同的資訊。
ROWS ：表的行數。
CHUNKS ：被劃分到表中的塊的數目。
SKIPPED ：由於錯誤或警告或過大，則跳過塊的數目。
TIME ：執行的時間。
TABLE ：被檢查的表名。
備註：主要觀察DIFFS列，標識差異數。

6.檢視差異（Slave庫執行）
select db, tbl, sum(this_cnt) as total_rows, count(*) as chunks  
 from checksums 
where ( master_cnt <> this_cnt OR master_crc <> this_crc OR isnull(master_crc) <> isnull(this_crc) )
 group by db, tbl; 

7.製造master、slave兩張不一樣的表
master：
use test;
create table test (id int);
insert into test values(1),(2),(3),(4),(5);
ALTER TABLE test ADD CONSTRAINT pk_name PRIMARY KEY(id);
mysql> select * from test.test;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
+------+
5 rows in set (0.00 sec)

slave：
mysql> select * from test.test;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
|    4 |
|    5 |
+------+
5 rows in set (0.00 sec)

mysql> delete from test.test where id=3;
Query OK, 1 row affected (0.02 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test.test;
+------+
| id   |
+------+
|    1 |
|    2 |
|    4 |
|    5 |
+------+
4 rows in set (0.00 sec)

先檢查test庫中表的差異：
[

[email protected] ~]# pt-table-checksum --nocheck-binlog-format --nocheck-plan --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --databases test -u'checksums' -p'oracle' -h192.168.1.23
            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
08-26T11:35:08      0      1        5       1       0   0.043 test.test

使主、從資料一致：
[

[email protected] ~]# pt-table-sync --print --execute --sync-to-master h=192.168.1.24,P=3306,u=checksums,p='oracle' --databases=test --tables=test
REPLACE INTO `test`.`test`(`id`) VALUES ('3') /*percona-toolkit src_db:test src_tbl:test src_dsn:P=3306,h=192.168.1.23,
p=...,u=checksums dst_db:test dst_tbl:test dst_dsn:P=3306,h=192.168.1.24,p=...,u=checksums lock:1 transaction:1 
changing_src:1 replicate:0 bidirectional:0 pid:8195 user:root host:mysql3*/;

或者打印出sql語句，人工干預到Slave庫執行（推薦）
pt-table-sync --print --sync-to-master h=192.168.1.24,P=3306,u=checksums,p='oracle' --databases=test --tables=test
pt-table-sync --print --sync-to-master h=192.168.1.24,P=3306,u=checksums,p='oracle' --replicate pt.checksums

#--sync-to-master ：指定一個DSN，即從的IP，他會通過show processlist或show slave status 去自動的找主。
#--replicate ：指定通過pt-table-checksum得到的表，這2個工具差不多都會一直用。
#--print ：列印，但不執行命令。
#--execute  ：執行命令。
備註：Slave需要授權主庫Drop 和Create Temporary Tables許可權

8.檢驗
slave：
mysql> select * from test.test;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
|  5 |
+----+
5 rows in set (0.00 sec)

重新執行一次pt-table-checksum，檢視是否還存在差異：
[[email protected] ~]# pt-table-checksum --nocheck-binlog-format --nocheck-plan --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --databases test -u'checksums' -p'oracle' -h192.168.1.23
            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
08-26T11:48:26      0      0        5       1       0   0.028 test.test

四、注意事項
1.採用replace into來修復主從不一致，必須保證被replace的表上有主鍵或唯一鍵，否則replace into退化成insert into，起不到修復的效果。這種情況下pt-table-sync會採用其他校驗和修復演算法，但是效率非常低，例如對所有列的group by然後求count(*)(表一定要有主鍵！)。
2.主從資料不一致需要通過replace into來修復，該sql語句必須是語句級。pt-table-sync會把它發起的所有sql語句都設定為statement格式，而不管全域性的binlog_format值。這在級聯A-B-C結構中，也會遇到pt-table-checksum曾經遇到的問題，引起行格式的中繼庫的從庫卡庫是必然。不過pt-table-sync預設會無限遞迴的對從庫的binlog格式進行檢查並警告。
3.由於pt-table-sync每次只能修復一個表，所以如果修復的是父表，則可能導致子表資料連帶被修復，這可能會修復一個不一致而引入另一個不一致；如果表上有觸發器，也可能遇到同樣問題。所以在有觸發器和主外來鍵約束的情況下要慎用。pt-table-sync工具同樣也不歡迎主從異構的結構。pt-table-sync工具預設會進行先決條件的檢查。
4.pt-table-sync在修復過程中不能容忍從庫延遲，這正好與pt-table-checksum相反。如果從庫延遲太多，pt-table-sync會長期持有對chunk的for update鎖，然後等待從庫的master_pos_wait執行完畢或超時。從庫延遲越大，等待過程就越長，主庫加鎖的時間就越長，對線上影響就越大。因此要嚴格設定max-lag。
5.對從庫資料的修復通常是在主庫執行sql來同步到從庫。因此，在有多個從庫時，修復某個從庫的資料實際會把修復語句同步到所有從庫。資料修復的代價取決於從庫與主庫不一致的程度，如果某從庫資料與主庫非常不一致，舉例說，這個從庫只有表結構，那麼需要把主庫的所有資料重新灌一遍，然後通過binlog同步，同時會傳遞到所有從庫。這會給線上帶來很大壓力，甚至拖垮叢集。正確的做法是，先用pt-table-checksum校驗一遍，確定不一致的程度：如果不同步的很少，用pt-table-sync直接修復；否則，用備份先替換它，然後用pt-table-sync修復。 說明： 這實際提供了一種對myisam備份的思路：如果僅有一個myisam的主庫，要為其增加從庫，則可以：先mysqldump出表結構到從庫上，然後啟動同步，然後用pt-table-sync來修復資料。

########################################

如何保證線上資料庫，主從一致，或者儘量少出問題?
1：使用innodb儲存引擎，每張表都要有主鍵，或者唯一性索引
2：設定innodb_flush_log_at_trx_commit = 1
3：使用binlog server
4：定期使用pt-table-checksum檢查資料的一致性

######################################

複製過濾：

1.M上把事件從二進位制日誌中過濾
引數：binlog-do-db
      binlog-ignore-db

2.S上事件從中繼日誌中過濾
引數：replicate_do_db
      replicte_do_table
      repicate_ingore_db
      repliacate_ignore_table
      replicate_write_db
      replicate_wild_do_table
      replicate_wild_ignore_table

##############################################################

伺服器硬體優化：
1：BIOS優化
開啟最大效能模式；
開啟最大PCIE ExpressSpeed
開始超執行緒
使用所有cpu核

2：底層磁碟
機械硬碟做成 RAID 1+0
有條件使用 PCIE SSD

3：OS優化
修改/etc/security/limits.conf，將mysql的nofile限制（soft、hard都需要修改）修改為65536
mysql的資料放在XFS檔案系統的磁碟
IPMI開啟，方便遠端管理

-------------------------------------
5.6半同步的BUG，5.7的修復方案：
5.6半同步流程：
1：master commit，寫binlog
2：傳送到slave的relay log
3：master不等slave返回ack，就在儲存引擎commit
所以，slave有可能丟失資料


5.7半同步流程：
1：master commit，寫binlog
2：傳送到slave的relay log
3：master等slave返回ack，才會在儲存引擎commit;
當master、slave之間網路超時，在超過時間限定之後，會由半同步轉變成非同步複製，
從而不能保證master、slave之間資料不一致。
而當master在等slave返回ack，還沒在儲存引擎commit時候宕機，就會出現slave比master多一條記錄。

-----------------------------------------------
relay-log-info：記錄SQL執行緒讀取Master binlog的位置，用於Slave宕機之後根據檔案中記錄的POS點恢復SQL執行緒
master-info：記錄I/O執行緒已經讀取到的Master binlog位置，用於Slave宕機後I/O執行緒根據檔案中記錄的POS點重新拉取binlog日誌。
sync_relay_log：
預設為10000，即每10000次sync_relay_log事件會重新整理到磁碟。為0則表示不重新整理，交由OS的cache控制。
sync_master_info:
若master-info-repository為FILE，當設定為0，則每次sync_master_info事件都會重新整理到磁碟，預設為10000次重新整理到磁碟；
若master-info-repository為TABLE，當設定為0，則表不做任何更新，設定為1，則每次事件會更新表 #預設為10000
sync_relay_log_info：
若relay_log_info_repository為FILE，當設定為0，交由OS重新整理磁碟，預設為10000次重新整理到磁碟；
若relay_log_info_repository為TABLE，且為INNODB儲存，則無論為任何值，則都每次evnet都會更新表。


問題：relay-log-info、master-info不是實時更新的，
如果sync_relay_log_info設定為1000，在999個事務的時候，slave宕機，則relay-log-info檔案未能更新，
則在slave重啟後，會根據上次記錄的POS點開始SQL執行緒，則slave重複執行這999個事務，會報主鍵衝突。
如果master-info設定為1000，在999個事務的時候，slave宕機，則master-info檔案未能更新，
則在slave重啟後，會根據上次記錄的POS點開始IO執行緒，slave則會從master重新拉取這999個事務，
然後重複執行這999個事務，會報主鍵衝突。
SQL執行緒和 SYNC不是在一個事務裡，所以sync_relay_log_info、sync_master_info無論設定多少都不能解決問題。


解決方案：
Mysql提供了兩個引數
relay-log-info-repository：將relay-log-info記錄到slave_relay_log_info表中;
master-info-repository：將master-info記錄到slave_master_info表中;
relay_log_recovery：當slave重啟後會根據slave_relay_log_info重新建立一個檔案，SQL執行緒會根據這個檔案進行恢復複製，
IO執行緒會讀取SQL執行緒的POS點，根據這個POS點向主庫申請拉去資料。
所以只要將 relay-log-info-repository = tabl，relay_log_recovery=ON 設定好即可解決問題。