日志错误：
大多数replication错误都是因为日志错误引起的。
主日志和中继日志都可能出错。
评判日志错误的辨别方法：
|
1
|
mysqlbinlog master_binlog_file > /dev/
null
|
屏幕有输出则表示这个binlog有错误，如果没有则表示binlog正常、
|
1
|
mysqlbinlog slave_binlog_file >/dev/
null
|
跳过日志错误1：
可以使用手动跳过日志错误，可能会造成数据不一致
如果主日志出错，可以再slave上执行（如果有多个错误可能需要多次操作）
|
1
2
3
|
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状态，根据日志信息跳过出错的日志：
|
1
2
3
4
5
|
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模式下，则需要以下操作：
|
1
2
3
4
5
6
7
8
|
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模式
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
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
|
|
1
|
sql_log_bin |
ON
全局参数，当前所发生的操作会记录到二进制日中、
|
|
1
|
mysql>
set
sql_log_bin=
OFF
;
|
表示不记录当前的操作到二进制日志中。接下来的操作会不会同步到slave，这样就会错误
|
1
2
3
4
5
6
7
8
9
10
|
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
|
|
1
2
|
mysql>
set
sql_log_bin=
ON
; 再次打开，
Query OK, 0
rows
affected (0.00 sec)
|
|
1
2
3
|
mysql>
insert
into
t1
values
(201); 这是201会被同步到salve，200确不会同步到slave
Query OK, 1 row affected (0.03 sec)
in
master
|
|
1
2
3
4
5
6
7
8
|
mysql>
select
*
from
t1;
+
------+
| id |
+
------+
| |
200
| 201 |
in
SLAVE
|
|
1
2
3
4
5
6
|
mysql>
select
*
from
t1;
+
------+
| id |
+
------+
| |
| 201 |
|
切回到master
|
1
|
mysql>delect
from
t1
where
id=200;
|
此步骤完了后，此操作记录到binlog，而且会同步到slave，此时slave报错，并指出master的那个binlog end_log_pos出错。
IN slave；
|
1
2
|
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
|
1
|
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，
|
1
2
3
4
5
6
7
8
9
|
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。另一台会自动更新到正常状态。
