mysql5.6利用GTIDs構建主從資料庫

wzq609發表於2015-07-15
MySql資料庫

【概念】什麼事GTIDS（Global Transactions Identifier）是MySQL5.6.5新加入的一項新特性。

  • 當使用GTIDS時，無論是在Master上提交事物還是在Slave上應用，每一個事物都可以被識別並跟蹤；
  • 新增新的Slave或者當發生故障需要將Master身份遷移到Slave上時，都無需考慮哪一個二進位制日誌以及哪個position，極大的簡化了操作步驟；
  • GTIDs是完全基於事務的。因此，不支援MYISAM儲存引擎；

 

【關於GTID】GTID由source_id和transaction_id兩部門組成。

  • source_id來自於server_uuid，可以在auto.cnf檔案中檢視；
  • tranction_id是一個序列數字，從小到達自動生成；

[root@t-db01 mysql]# cat auto.cnf
[auto]
server-uuid=268e23d1-2216-11e5-abcc-000c296ecd05

 

mysql> show global variables like 'gtid_executed';
+---------------+-----------------------------------------------------+
| Variable_name | Value                                                                   |
+---------------+-----------------------------------------------------+
| gtid_executed  | 268e23d1-2216-11e5-abcc-000c296ecd05:1-28     |
+---------------+-----------------------------------------------------+

 

【構建主從資料庫】

環境說明：

  主庫資訊 從庫資訊
資料庫版本 5.6.23 5.6.23
IP地址 192.168.47.169 192.168.47.186
同步資料庫 JOHN_DB  
同步使用者 repl  

 

 

1、主庫引數的設定

server_id = 1
binlog-format=ROW  #建議使用ROW格式
log-bin=mysql-bin      #開啟binlog
report-port=3306
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=true
replicate_do_db=JOHN_DB

 

2、從庫引數的設定

server_id = 2
log-bin=mysql-bin
report-port=3306
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=true
replicate_do_db=JOHN_DB
skip-slave-start    #啟動的時候自動開啟復制

 

檢查gtid是否啟用：show global variables like ‘%gtid%’;

image

 

3、在主庫上面使用者的建立

grant replication slave on JOHN_DB.* to 'repl'@'192.168.47.186' identified by 'repl';

 

4、進行從庫資料的初始化

操作的步驟跟5.5的步驟一樣，這邊就偷懶不再重複了；

 

5、配置從庫連線主庫

從庫連線主庫：
change master to master_host='192.168.47.169', master_user='repl',master_password='repl',master_auto_position=1;

啟動從庫：
start slave；

檢查狀態：
show slave status\G；

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.47.169
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 485
               Relay_Log_File: t-db02-relay-bin.000012
                Relay_Log_Pos: 695
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: JOHN_DB
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 485
              Relay_Log_Space: 1150
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 31
                  Master_UUID: 268e23d1-2216-11e5-abcc-000c296ecd05
             Master_Info_File: /data/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
          Retrieved_Gtid_Set: 268e23d1-2216-11e5-abcc-000c296ecd05:1-29
            Executed_Gtid_Set: 268e23d1-2216-11e5-abcc-000c296ecd05:1-29
                Auto_Position: 1
1 row in set (0.02 sec)

ERROR:
No query specified

自動找到binlog位置，並進行同步；

經過以上操作便完成了mysql主從架構的搭建；

 

【常見問題的處理方法】

1、場景的模擬

步驟一：主庫上面建立表john，並插入3行資料。（這個時候從庫和主庫的資料是一致的）

mysql> select * from john;
+------+
| id   |
+------+
| 1    |
| 2    |
| 3    |
+------+
3 rows in set (0.19 sec)

 

步驟二：從庫關閉slave狀態

mysql> stop slave；

 

步驟三：主庫關閉寫binlog

mysql>  set sql_log_bin=off;   關閉
Query OK, 0 rows affected (0.03 sec)

 

步驟四：主庫插入值4

mysql> insert into john values(4);
Query OK, 1 row affected (0.04 sec)

 

步驟五：主庫啟動binlog

mysql> set sql_log_bin=on;
Query OK, 0 rows affected (0.00 sec)

 

步驟六：主庫插入值 5

mysql> insert into john values(5);
Query OK, 1 row affected (0.00 sec)

 

經過以上步驟，主庫和從庫中john的值已經不一致了；

主庫如下：

image

 

從庫如下:

image 

 

步驟六：修改主庫id為4的行，這個時候從庫就會報錯了

image

Retrieved_Gtid_Set: a989adc2-2a8e-11e5-a308-000c296ecd05:1-30  主庫的Gtid序號
Executed_Gtid_Set: a989adc2-2a8e-11e5-a308-000c296ecd05:1-29  從庫執行Gtid序號

 

2、問題原因：由於id=4是沒有寫日誌的，所以id=4並沒有同步到從庫，當主庫刪除id=4這條記錄的時候，從庫找不到這條記錄所以報錯了；

 

3、解決方法：GTIDs模式下的主從問題，操作如下：

mysql> stop slave;
mysql> set GTID_NEXT=’268e23d1-2216-11e5-abcc-000c296ecd05:1-30’;    #跳過當前從庫的該序號
mysql> BEGIN;
mysql> COMMIT;
mysql> SET GTID_NEXT=’AUTOMATIC’;
mysql> START SLAVE;

 

經過以上操作完成了基於GTIDs的主從資料庫的配置和常見問題的處理，單從便捷的角度上確實提高了主從搭建的速度；

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12679300/viewspace-1733655/，如需轉載，請註明出處，否則將追究法律責任。

相關文章