概述:

mysql的主從複製是十分經典的一個應用，但是主從之間總會有資料一致性（data consistency ）的問題，一般情況從庫會落後主庫幾個小時，而且在傳統一主多從(mysql5.6之前)的模型中當master down掉後，我們不只是需要將一個slave提成master就可以，還要將其他slave的同步目的地從以前的master改成現在master，而且bin-log的序號和偏移量也要去檢視，這是十分不方便和耗時的，但mysql5.6引入gtid之後解決了這個問題，本次文章我們會講解傳統的資料庫主從切換，mysql5.6之後的主從切換。
系統版本:Red Hat Enterprise Linux Server release 7.1 (Maipo)
mysql版本:
mysql叢集框圖:

1.傳統主從切換

沒有基於GTID的mysql主從複製在我之前的部落格中有記錄 運維筆記32 （mysql的主從複製）
或者參考官方文件(強力推薦，仔細讀過後會發現寫的是真心好)配置基於日誌位置的主從複製

master伺服器配置:

[mysqld]
binlog-do-db=test   
log-bin=mysql-bin
server-id=1

建立複製使用者並授權:

mysql> create user repl;
mysql> grant replication slave on *.* to 'repl' @'172.25.3.%' identified by
 
 'redhat';

從伺服器1配置

server-id=2

將主伺服器設定為master.mo.com

CHANGE MASTER TO MASTER_HOST='172.25.3.102',MASTER_USER='repl',MASTER_PASSWORD='redhat';

從伺服器2配置

server-id=3

將主伺服器設定為master.mo.com

CHANGE MASTER TO MASTER_HOST='172.25.3.102',MASTER_USER='repl',MASTER_PASSWORD='redhat';

現在開啟salve1,slave2的複製。

start slave;

以上只是一個非常簡易的主從配置，我們在接下來會一點點豐富，現在建立一個test庫，並寫入加入一些資料。

    create database test;
    create table test(id not int auto_increment,
    name varcahr(30),
    school varchar(30)
);
start transaction;
insert into user values(NULL,'mo','test');
insert into user values(NULL,'li','test');
commit;

master與slave1,slave2同步成功。

通過該圖可以看出同步成功。
現在開始模擬主從切換
首先將master的mysql關閉

[root@master ~]# /etc/init.d/mysqld stop
Shutting down MySQL.... SUCCESS!

現在檢視slave上的狀態

        Slave_IO_Running: Connecting
            Slave_SQL_Running: Yes

IO執行緒一直在嘗試連線主機，我們把master都關掉了，任他怎麼連都是連不上的，所以開始將原來的slave1提升成master。
其實將slave1提升成主，並不需要在slave1上做什麼，而是要在其他slave上做設定，而且要根據slave1上的日誌號和日誌偏移來確定新的主從複製。
現在檢視下slave1上的日誌

mysql> show binlog events\G
Empty set (0.00 sec)

。。。不存在日誌，我們看下data目錄

slave2-relay-bin.000001
ca.pem           localhost.localdomain.err  private_key.pem     slave2-relay-bin.000002
client-cert.pem  localhost.localdomain.pid  public_key.pem      slave2-relay-bin.index

發現這裡只有relay-log，我們查閱官網的文件

Normally, a slave does not write any updates that are received from a master server to its own binary log. This option causes the slave to write the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the --log-bin option to enable binary logging.

簡單翻譯:

一般情況，一個從伺服器不會向他的二進位制日誌更新任何從主伺服器接收到的資料，log-slave-updates選項讓從伺服器也更新他本機的二進位制日誌。為了讓這個選項生效，我們還必須指定log-bin引數。

看到這裡，我們在看下自己的配置檔案，終於發現了問題，我們的從伺服器根本什麼都沒有配置，data目錄下的realy-bin並不沒有master上資料更新的，而且他也不會把自己更新的資料寫入二進位制檔案(This option causes the slave to write the updates performed by its SQL thread to its own binary log.)，所以要讓slave成為master必須新增log-bin，和log-slave-updates。
修改後的slave1,slave2上的配置檔案
slave1:

log-bin=mysql-bin
log-slave-updates=ON
server-id=2 

slave2:

log-bin=mysql-bin
log-slave-updates=ON
server-id=3 

檢視slave1上的日誌

mysql> show binlog events\G
*************************** 1. row ***************************
   Log_name: mysql-bin.000001
        Pos: 4
 Event_type: Format_desc
  Server_id: 2
End_log_pos: 123
       Info: Server ver: 5.7.11-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000001
        Pos: 123
 Event_type: Previous_gtids
  Server_id: 2
End_log_pos: 154
       Info: 
2 rows in set (0.00 sec)

確定當前的複製檔案為mysql-bin.000001，當前的檔案偏移為154。這兩個都要幾下，因為要讓其他slave以slave1為master去同步，依靠的就是這個日誌。
slave2上配置

mysql> CHANGE MASTER TO MASTER_HOST='172.25.3.103', MASTER_USER='repl', MASTER_PASSWORD='redhat'  ,MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154;

開啟slave,檢視slave2狀態

       Master_Host: 172.25.3.103
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
...omit
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

在slave1上寫入資料，觀察slave2的同步

從上圖可以看出，我們在筆記本[1]（slave1）上插入資料後，在筆記本[2]（slave2）上可以檢視到，說明切換成功。雖然切換成功，但是因為需要去查詢新提升的資料庫的日誌號和偏移id，整個過程非常麻煩，而且容易出錯，在mysql5.6版本更新了GTID之後一切都改變了，讓我們下面來介紹一下。

2.基於GTID的主從複製

官方文件關於gtid的定義:

A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup. There is a 1-to-1 mapping between all transactions and all GTIDs.

簡要翻譯:通用事務識別符號是一個與每個在伺服器上提交事務相關的識別符號，這個表示符不僅在創造它的伺服器上是獨一無二的，而且他在所有的從伺服器上也是獨一無二的，這是一個識別符號與事務一對一的符號。
(翻譯水平有限。。。英文好的同學自動無視)
GTID的格式就像下面這樣:

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

用冒號分割開，左半部分是mysql的uuid，右半部份是事務的id。
我們通過下面方式檢視我們的master與slave的uuid

[root@master data]# cat auto.cnf 
[auto]
server-uuid=b7f3c1bc-12b5-11e7-a4ba-5254000d5ada

[root@slave1 data]# cat auto.cnf 
[auto]
server-uuid=6447f007-12c2-11e7-91f7-525400d18cb9

現在我們要恢復環境，重新讓域名為master的伺服器變成mysql主資料庫，但是大家要知道，在設定主從複製之前，我們的主資料庫與從資料庫一定要先是一致的，否則會出現一種情況，我有兩臺伺服器,mster和slave，但現在他們並沒有做主從，我準備為master上的test庫做一次主從複製，但是，slave上沒有這個test庫，現在做主從就會出問題，因為，slave去讀取master的日誌的時候發現要向一個test的庫插入資料，可是我都沒有這個庫，這時主從同步就會卡在這裡。

如上圖，由於我們剛才將master在主從中剔除了，導致後續更新的資料，master中並沒有，為了穩妥起見，我們使用1中的根據偏移量來進行主從的同步。

從上圖可以看出，開始修改時候的二進位制日誌是’mysql-bin.000001’，偏移是4。所以我們從這裡開始同步。
在master上輸入如下

mysql> CHANGE MASTER TO MASTER_HOST='172.25.3.103',MASTER_USER='repl',MASTER_PASSWORD='redhat',MAASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=4;

現在兩邊資料同步了。
我們開始帶有gtid的主從複製！

master配置:
my.cnf:

[mysqld]
binlog-do-db=test
log-bin=mysql-bin
server-id=1
gtid-mode=ON
enforce-gtid-consistency

slave1配置

[mysqld]
read-only
socket=/usr/local/lnmp/mysql/data/mysql.sock
gtid-mode=ON
enforce-gtid-consistency
log-bin=mysql-bin
log-slave-updates=ON
server-id=2

slave2只是將slave1的配置修改中的server-id修改一下。
現在關閉master，slave2的slave。並重啟所有節點。

現在我們將slave1,slave2都將master指向master.mo.com，並且加上
MASTER_AUTO_POSITION = 1。讓slave根據gtid自動同步。’

CHANGE MASTER TO MASTER_HOST='172.25.3.102',MASTER_USER='repl',MASTER_PASSWORD='redhat',MASTER_AUTO_POSITION=1;

現在開啟slave。
觀察一下是否同步成功。

根據圖片可以看到，slave開啟成功。而且是基於GTID的！
現在在主庫上插入一些資料，觀察從資料庫的日誌資訊。
要查詢slave的二進位制日誌，首先要看下data目錄，二進位制日誌檔案都有什麼

[[email protected] data]# ls
auto.cnf         ibtmp1                     mysqld_safe.pid     slave1.mo.com.err
ca-key.pem       localhost.localdomain.err  mysql.sock          slave1.mo.com.pid
ca.pem           localhost.localdomain.pid  mysql.sock.lock     slave1-relay-bin.000001
client-cert.pem  master.info                performance_schema  slave1-relay-bin.000002
client-key.pem   mysql                      private_key.pem     slave1-relay-bin.index
ib_buffer_pool   mysql-bin.000001           public_key.pem      sys
ibdata1          mysql-bin.000002           relay-log.info      test
ib_logfile0      mysql-bin.000003           server-cert.pem
ib_logfile1      mysql-bin.index            server-key.pem

發現最新的二進位制是mysql-bin.000003，我們在進到資料庫，檢視下這個日誌。

mysql> show binlog events in 'mysql-bin.000003'\G

OMIT...
*************************** 3. row ***************************
   Log_name: mysql-bin.000003
        Pos: 154
 Event_type: Gtid
  Server_id: 1
End_log_pos: 219
       Info: SET @@SESSION.GTID_NEXT= 'b7f3c1bc-12b5-11e7-a4ba-5254000d5ada:1'
*************************** 4. row ***************************

看到日誌中有一行是設定下次的GTID，現在我們再插入一條並觀察日誌。

*************************** 8. row ***************************
   Log_name: mysql-bin.000003
        Pos: 416
 Event_type: Gtid
  Server_id: 1
End_log_pos: 481
       Info: SET @@SESSION.GTID_NEXT= 'b7f3c1bc-12b5-11e7-a4ba-5254000d5ada:2'

發現了沒有，GTID中冒號後面變成2了。

基於GTID的主從複製已經搭建完成，現在將master down掉。
讓slave1提成master，這一過程只需要修改slave2，而且完全不用去看slave1的任何狀態。

CHANGE MASETR TO MASTER_HOST='172.25.3.103',MASTER_USER='repl',MASTER_PASSWORD='redhat',MASTER_AUTO_POSITION=1

start slave，
在slave1上插入資料。

由圖可見，同步成功。十分方便，那麼現在再考慮一個問題，如果master恢復了，讓master從新成為主如何做呢？
當然還是先資料同步，之後再將MASTER切換成主，但因為有了MASTER_AUTO_POSITION=1,我們同步資料的時候都不需要去檢視偏移了(具體原理還沒有找到)。