GTID模式下的replication，跳過錯誤日誌的解決方法

日誌錯誤：

大多數replication錯誤都是因爲日誌錯誤引起的。

主日誌和中繼日誌都可能出錯。

評判日誌錯誤的辨別方法：

mysqlbinlog  master_binlog_file > /dev/null

屏幕有輸出則表示這個binlog有錯誤，如果沒有則表示binlog正常、

mysqlbinlog  slave_binlog_file  >/dev/null

跳過日誌錯誤1：

可以使用手動跳過日誌錯誤，可能會造成數據不一致

如果主日誌出錯，可以再slave上執行（如果有多個錯誤可能需要多次操作）

mysql>stop slave;
mysql>set global sql_slave_skip_counter=1；
mysql>start slave;

這個方法不適用於DTID模式的replication，GTIDs模式不允許sql_slave_skip_counter

跳過錯誤日誌2:  不支持GTID

如果是中舉日誌出錯，可以再slave上查看replication狀態，根據日誌信息跳過出錯的日誌：

mysql>stop slave;
mysql>change master to 
master_log_file='relay_master_log_file';
master_log_pos=<exec_master_log_pos>;
mysql>start slave;

跳過錯誤日誌3 ： GDIT的好處是，計算機自行處理，無需像以前的那樣繁瑣。

如果master上的binlog除了問題，導致slave無法繼續，

如果replication工作在GTID模式下，則需要以下操作：

mysql>stop slave;
mysql>set GTID_NEXT='uuid.next_id';  
mysql>begin;
mysql>commit;
mysql>set GTID_NEXT='AUTOCOMMIT';
mysql>start slave;
uuid:nextid 例如：8a1f84c4-9d67-11e4-8a9a-3085a9eb338b:12
into

模擬故障：基於DTID模式

in master：
mysql>use viewdb
 
mysql> select * from t1;
+------+
| id   |
+------+
|  112 |
|  113 |
|  114 |
|  115 |
|  116 |
|  117 |
|  118 |
|  119 |
|  120 |
| 1000 |
|  110 |
|  109 |
mysql>show vaiiables like "%bin%" 找到 sql_bin_log

sql_log_bin  | ON       全局參數，當前所發生的操作會記錄到二進制日中、

mysql> set sql_log_bin=OFF;

表示不記錄當前的操作到二進制日誌中。接下來的操作會不會同步到slave，這樣就會錯誤

mysql> insert into t1 values (200);
Query OK, 1 row affected (0.00 sec)
mysql> select * from t1;
+------+
| id   |
+------+
| |
|  200 |
+------+
13 rows in set (0.00 sec

    

mysql> set sql_log_bin=ON; 再次打開，
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t1 values (201); 這是201會被同步到salve，200確不會同步到slave
Query OK, 1 row affected (0.03 sec)
in   master

mysql> select * from t1;
+------+
| id   |
+------+
|  |
   200 
|  201 |
in SLAVE

mysql> select * from t1;
+------+
| id   |
+------+
|  |
|  201 |

 切回到master

mysql>delect from t1 where id=200;

此步驟完了後，此操作記錄到binlog，而且會同步到slave，此時slave報錯，並指出master的那個binlog  end_log_pos出錯。

 

IN slave；

mysql>show salve status\G;
Last_SQL_Error: Could not execute Delete_rows event on table viewdb.t1; Can't find record in 't1', Error_code: 1032;

handler error HA_ERR_END_OF_FILE; the event's master log localhost-bin.000006, end_log_pos 1360

並且：

 Retrieved_Gtid_Set: 61816754-9d68-11e4-8a9f-000c29c1d1ea:1-18

 Executed_Gtid_Set: 61816754-9d68-11e4-8a9f-000c29c1d1ea:1-17

不一致

切回到master

mysql>insert into t1 valuses(202);

in slave

這時由於slave故障，所以slave不再會有任何新的數據同步過來。

Retrieved_Gtid_Set: 61816754-9d68-11e4-8a9f-000c29c1d1ea:1-19

Executed_Gtid_Set: 61816754-9d68-11e4-8a9f-000c29c1d1ea:1-17

這是我們跳過這個error，

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> set gtid_next='61816754-9d68-11e4-8a9f-000c29c1d1ea:18';
mysql> begin;
mysql> commit;
mysql> set gtid_next='automatic';
mysql> start slave;
mysql>show slave status\G;
mysql>select * from t1;  發現數據已經保持一致。

  

gtid的好處是，如果有兩臺slave，只修復一臺slave。另一臺會自動更新到正常狀態。