MySQL GTID复制Slave跳过错误事务Id以及复制排错问题总结

by admin on 2019年12月15日

某Slave报错信息:

 

MySQL
GTID是在传统的mysql主从复制的基础之上演化而来的产物,即通过UUID加上事务ID的方式来确保每一个事物的唯一性。这样的操作方式使得我们不再需要关心所谓的log_file和log_Pos,只是简单的告诉从库,从哪个服务器上去找主库就OK了。简化了主从的搭建以及failover的过程,同时比传统的复制更加安全可靠。由于GTID是连续没有空洞的,因此主从库出现数据冲突时,可以通过注入空事物的方式进行跳过。本文主要讲述GTID主从架构的错误处理方式。

 

mysql> show slave status\G;

GTID复制典型的复制错误有两种:
1,数据对象级别的错误,包括主库上update的数据在从库上不存在,主从逐渐冲突,库表索引等对象的冲突等等,
  
如果是纯粹的跳过错误的话,这一类的错误需要跳过思路是找到主库binlog中对应的事务Id然后在从库上跳过即可。
2,日志找不到的错误,也即从库在执行利用主库上的binlog执行对应的事务的时候,因为主库上日志被删除,找不到对应的日志的错误
  
这一类的错误,根据主库的gtid_purged,更新从库的gtid_purged,也就是告诉从库,直接跳过主库中被删除的日志。

一、GTID的相关特性

配置MySQL GTID
主从复制 
基于mysqldump搭建gtid主从

图片 1图片 2

本文说的是第一种错误。

二、GTID如何跳过事务冲突

    很多无法预料的情形导致mysql主从发生事务冲突,主从失败或停止的情形,即需要修复主从
    对于GTID方式的主从架构而言,更多的是处理事务冲突来修复主从
    GTID不支持通过传统设置sql_slave_skip_counter方法来跳过事务
    方法:通过注入空事务来填补事务空洞,等同于传统复制的(set global sql_slave_skip_counter = 1)
    步骤:
            stop slave;
            set gtid_next='xxxxxxx:N'; --指定下一个事务执行的版本,即想要跳过的GTID
            begin;
            commit;  --注入一个空事物
            set gtid_next='AUTOMATIC' --自动的寻找GTID事务。
            start slave; --开始同步
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.206.140
                  Master_User: u_repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 499
               Relay_Log_File: localhost-relay-bin.000002
                Relay_Log_Pos: 367
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1007
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e2c7c0f-0908-11e7-8230-000c29ab7544:1' at master log mysql-bin.000001, end_log_pos 313. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 1513
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1007
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e2c7c0f-0908-11e7-8230-000c29ab7544:1' at master log mysql-bin.000001, end_log_pos 313. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 140
                  Master_UUID: 9e2c7c0f-0908-11e7-8230-000c29ab7544
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 170316 04:25:29
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 9e2c7c0f-0908-11e7-8230-000c29ab7544:1-2
            Executed_Gtid_Set: 347cbac6-0906-11e7-b957-000c2981a46e:1,
c59a2526-08fd-11e7-a5c7-000c296f2953:1-2
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

ERROR: 
No query specified

背景:安装完master之后,修改root密码的时候忘了关闭binlog,导致update
mysql.user表的时候记录了binlog 

三、GTID事务冲突的几种常见类型

    1、主库新增记录,从库提示主键冲突
    2、主库对象可更新,从库无对应的对象可更新
    3、主库对象可删除,从库无对应的对象可删除
    4、通过延迟从修复主库意外删除的对象
    5、主库日志被purged的情形
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

View Code

开启GTID的复制后,直接报错:
Could not execute Update_rows event on table mysql.user; Can’t find
record in ‘user’, Error_code: 1032; handler error
HA_ERR_KEY_NOT_FOUND; the event’s master log binlog.000002,
end_log_pos 744

四、示例演示

当前演示的主从架构图
# mysqlrplshow --master=root:pass@192.168.1.233:3306 --discover-slaves-login=root:pass --verbose
WARNING: Using a password on the command line interface can be insecure.
# master on 192.168.1.233: ... connected.
# Finding slaves for master: 192.168.1.233:3306

# Replication Topology Graph
192.168.1.233:3306 (MASTER)
   |
   +--- 192.168.1.245:3306 [IO: Yes, SQL: Yes] - (SLAVE)
   |
   +--- 192.168.1.247:3306 [IO: Yes, SQL: Yes] - (SLAVE)

(root@192.168.1.233)[tempdb]>show slave hosts;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | Host          | Port | Master_id | Slave_UUID                           |
+-----------+---------------+------+-----------+--------------------------------------+
|       245 | 192.168.1.245 | 3306 |       233 | 78336cdc-8cfb-11e6-ba9f-000c29328504 |
|       247 | 192.168.1.247 | 3306 |       233 | 13a26fc1-555a-11e6-b5e0-000c292e1642 |
+-----------+---------------+------+-----------+--------------------------------------+

--演示的mysql版本
(root@192.168.1.233)[tempdb]>show variables like 'version';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| version       | 5.7.12-log |
+---------------+------------+

--查看gtid是否开启
(root@192.168.1.233)[tempdb]>show variables like '%gtid_mode%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | ON    |
+---------------+-------+

--主库上面可以看到基于gtid的dump线程,如下
(root@192.168.1.233)[tempdb]>show processlist;
+----+------+-----------------------+--------+------------------+------+
| Id | User | Host                  | db     | Command          | Time |
+----+------+-----------------------+--------+------------------+------+
| 17 | repl | node245.edq.com:52685 | NULL   | Binlog Dump GTID | 2738 |
| 18 | repl | node247.edq.com:33516 | NULL   | Binlog Dump GTID | 2690 |
| 24 | root | localhost             | tempdb | Query            |    0 |
+----+------+-----------------------+--------+------------------+------+
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46

GTID的复制对于错误信息的可读性不是很好,但可以通过错误代码(1007)从监控表replication_applier_status_by_worker查看:

图片 3

1、从库报主键重复(Errno: 1062)

(root@Master)[tempdb]>create table t1 (
            -> id tinyint not null primary key,ename varchar(20),blog varchar(50));

(root@Master)[tempdb]>insert into t1 
            -> values(1,'leshami','http://blog.csdn.net/leshami');

(root@Master)[tempdb]>insert into t1 
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

(root@Master)[tempdb]>set sql_log_bin=off;

(root@Master)[tempdb]>delete from t1 where ename='robin';

(root@Master)[tempdb]>set sql_log_bin=on;

(root@Master)[tempdb]>insert into t1 
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

-- 从库状态报错,提示重复的primary key
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
Last_Errno: 1062
Last_Error: Could not execute Write_rows event on table tempdb.t1; Duplicate entry '2' for key 'PRIMARY', 
                        Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
                        the event's master log node233-binlog.000004, end_log_pos 4426
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-90
 Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-89
     Auto_Position: 1

-- 如下解决方案,可以通过删除重库的这条记录
(root@Slave)[tempdb]>stop slave;

(root@Slave)[tempdb]>delete from t1 where ename='robin';

(root@Slave)[tempdb]>start slave;

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-90
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-90,
 78336cdc-8cfb-11e6-ba9f-000c29328504:1  --这里多了一个GTID,注意这个是从库上执行的,这里的UUID跟IP 245的UUID一致
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

(root@Slave)[tempdb]>show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 78336cdc-8cfb-11e6-ba9f-000c29328504 |
+---------------+--------------------------------------+
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
mysql> select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER=1007\G

网上有非常多的跳过GTID复制报错的文章,
当然GTID复制报错的原因有两种:
一种是数据不一致引起的(主库事物在从库上找不到对应数据,或者是数据主键冲突,索引冲突之类的)
另一种是主库上事物日志被清理,从库找不到主库的要重放的事物日志引起的(Got
fatal error 1236 from master when reading data from binary log:)
显然这里是因为数据不一致引起的错误,最主要的是如何找到引起复制错误的事物号,然后跳过这个事物?
之前注意过这个细节问题,这次果然又遇到了。

2、从库报找不到对应的被更新的记录(Errno: 1032)

--首先在从库上删除leshami这条记录
(root@Slave)[tempdb]>delete from t1 where ename='leshami';

--接下来再主库尝试更新leshami这条记录
(root@Master)[tempdb]>update t1 set 
            -> blog='http://blog.csdn.net/robinson_0612' where ename='leshami';

Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

-- 查看从库状态
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows event on table tempdb.t1; Can't find record in 't1',
                                Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;
                            the event's master log node233-binlog.000004, end_log_pos 4769
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-91
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-90,
        78336cdc-8cfb-11e6-ba9f-000c29328504:1-2

-- 通过mysqlbinlog在主服务器上寻找报错的binglog日志文件及位置,找到对应的SQL语句,如下所示
-- update中的where后面的部分为更新前的数据,set部分为更新后的数据,因此可以将更新前的数据插入到从库
# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /data/node233-binlog.000004|grep -A '10' 4769
#161009 13:46:34 server id 233 end_log_pos 4769 CRC32 0xb60df74e Update_rows: table id 147 flags: STMT_END_F
### UPDATE `tempdb`.`t1`
### WHERE
###   @1=1 /* TINYINT meta=0 nullable=0 is_null=0 */
###   @2='leshami' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */
###   @3='http://blog.csdn.net/leshami' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */
### SET
###   @1=1 /* TINYINT meta=0 nullable=0 is_null=0 */
###   @2='leshami' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */
###   @3='http://blog.csdn.net/robinson_0612' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */
# at 4769
#161009 13:46:34 server id 233  end_log_pos 4800 CRC32 0xa9669811       Xid = 1749
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;   

(root@Slave)[tempdb]>select * from t1;
+----+-------+------------------------------------+
| id | ename | blog                               |
+----+-------+------------------------------------+
|  2 | robin | http://blog.csdn.net/robinson_0612 |
+----+-------+------------------------------------+

(root@Slave)[tempdb]>stop slave sql_thread;

(root@Slave)[tempdb]>insert into t1 values(1,'leshami','http://blog.csdn.net/leshami');

(root@Slave)[tempdb]>start slave sql_thread;

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-91
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-91,
                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-3
                Auto_Position: 1
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62

图片 4图片 5

 

3、从库找不到对应的被删除的记录(Errno: 1032)

-- 如果是在主库上删除记录,而从库上找不到对应的记录,则可以直接跳过该事务
-- 下面我们首选在从库上删除一条记录
(root@Slave)[tempdb]>delete from t1 where ename='robin';

-- 接下来在主库上删除该记录
(root@Master)[tempdb]>delete from t1 where ename='robin';

-- 从库端提示无法找到对应的记录
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
Last_SQL_Error: Could not execute Delete_rows event on table tempdb.t1; Can't find record in 't1',
                Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; 
                the event's master log node233-binlog.000004, end_log_pos 5070
Last_SQL_Error_Timestamp: 161009 15:08:06
    Master_SSL_Crl: 
Master_SSL_Crlpath: 
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-92
 Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-91,
                    78336cdc-8cfb-11e6-ba9f-000c29328504:1-4
     Auto_Position: 1      

-- 下面通过注入空事务来跳过
(root@Slave)[tempdb]>stop slave sql_thread;

(root@Slave)[tempdb]>set gtid_next='1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:92';

(root@Slave)[tempdb]>begin;commit;

(root@Slave)[tempdb]>set gtid_next='AUTOMATIC';

(root@Slave)[tempdb]>start slave sql_thread;

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-92
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-92,
                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
mysql> select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER=1007\G
*************************** 1. row ***************************
         CHANNEL_NAME: 
            WORKER_ID: 2
            THREAD_ID: NULL
        SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: 9e2c7c0f-0908-11e7-8230-000c29ab7544:1
    LAST_ERROR_NUMBER: 1007
   LAST_ERROR_MESSAGE: Worker 1 failed executing transaction '9e2c7c0f-0908-11e7-8230-000c29ab7544:1' at master log mysql-bin.000001, end_log_pos 313; Error 'Can't create database 'mydb'; database exists' on query. Default database: 'mydb'. Query: 'create database mydb'
 LAST_ERROR_TIMESTAMP: 2017-03-16 04:25:29
1 row in set (0.00 sec)

如何找到造成复制错误对应的事物Id?

4、延迟从修复主库意外truncate

-- 主库上面新增表及记录             
(root@Master)[tempdb]>create table t2 (id tinyint not null primary key, 
        -> ename varchar(20),blog varchar(50));

(root@Master)[tempdb]>insert into t2  
            -> values(1,'leshami','http://blog.csdn.net/leshami');

(root@Master)[tempdb]>insert into t2  
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

(root@Master)[tempdb]>select * from t2;
+----+---------+------------------------------------+
| id | ename   | blog                               |
+----+---------+------------------------------------+
|  1 | leshami | http://blog.csdn.net/leshami       |
|  2 | robin   | http://blog.csdn.net/robinson_0612 |
+----+---------+------------------------------------+

--先将从库配置为延迟从
(root@Slave)[tempdb]>stop slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>CHANGE MASTER TO MASTER_DELAY = 300;
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    SQL_Delay: 300  

root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-99
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-99,
                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4
                Auto_Position: 1

--查看主库上的binglog gtid
(root@Master)[tempdb]>show master status\G
*************************** 1. row ***************************
             File: node233-binlog.000004
         Position: 6970
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-99
1 row in set (0.00 sec)

--在主库上truncate t2
(root@Master)[tempdb]>truncate table t2;
Query OK, 0 rows affected (0.03 sec)

--再次查看主库上的binglog gtid,有99变成了100,这个100即是我们需要跳过的ID
(root@Master)[tempdb]>show master status\G
*************************** 1. row ***************************
             File: node233-binlog.000004
         Position: 7121
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100
1 row in set (0.00 sec)

--从库上跳过被意外truncate的事务
(root@Slave)[tempdb]>stop slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>set gtid_next='1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100';
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>set gtid_next='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: Master
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: node233-binlog.000004
          Read_Master_Log_Pos: 7121
               Relay_Log_File: node245-relay-bin.000003
                Relay_Log_Pos: 2982
        Relay_Master_Log_File: node233-binlog.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
             ...........................         
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,
                                                             78336cdc-8cfb-11e6-ba9f-000c29328504:1-4
                Auto_Position: 1

-- 很多时候我们并不知道表何时被truncate,因此可以从binlog日志得到其gtid
-- 如下所示,可以得到这串 SET @@SESSION.GTID_NEXT= '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100'
-- 100即为这个truncate对应的gtid的事务号
# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /data/node233-binlog.000004|grep -i \
> "truncate table t2" -A3 -B10  
###   @3='http://blog.csdn.net/robinson_0612' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */
# at 6939
#161009 18:04:58 server id 233  end_log_pos 6970 CRC32 0x71c5121c     Xid = 1775
COMMIT/*!*/;
# at 6970
#161009 18:08:42 server id 233 end_log_pos 7035 CRC32 0x00ba9437 GTID last_committed=26 sequence_number=27
SET @@SESSION.GTID_NEXT= '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100'/*!*/;
# at 7035
#161009 18:08:42 server id 233 end_log_pos 7121 CRC32 0x5a8b9723 Query thread_id=26 exec_time=0 error_code=0
SET TIMESTAMP=1476007722/*!*/;
truncate table t2
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122

View Code

对于slave status中的信息,注意如下两行
Retrieved_Gtid_Set: 6d257f5b-5e6b-11e8-b668-5254003de1b6:1-547
Executed_Gtid_Set:
Retrieved_Gtid_Set是slave接收到的事务的信息,
Executed_Gtid_Set是slave已经执行的slave的信息,这里没有任何信息,意味着复制的时候从库遇到主库的第一个事物Id就发生了错误
也就是说第一个事务复制就不能执行,为什么第一个事务就无法正常复制,按道理,跳过
6d257f5b-5e6b-11e8-b668-5254003de1b6:1就可以的。

5、主库binlog被purge的情形(Errno: 1236)

-- 首先停止从库,模拟从库被意外宕机
(root@Slave)[tempdb]>stop slave;
Query OK, 0 rows affected (0.08 sec)

--在主库上进行相应的操作
--此时主库上的gtid_purged为空
(root@Master)[tempdb]>show variables like '%gtid_purged%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_purged   |       |
+---------------+-------+

--查看主库binlog
(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000001 |   1362104 |
| node233-binlog.000002 |      1331 |
| node233-binlog.000003 |       217 |
| node233-binlog.000004 |      7121 |
+-----------------------+-----------+

(root@Master)[tempdb]>select * from t1;
+----+---------+------------------------------------+
| id | ename   | blog                               |
+----+---------+------------------------------------+
|  1 | leshami | http://blog.csdn.net/robinson_0612 |
|  2 | robin   | http://blog.csdn.net/leshami       |
+----+---------+------------------------------------+

--从主库删除记录
(root@Master)[tempdb]>delete from t1;

--切换日志
(root@Master)[tempdb]>flush logs;

--新增记录
(root@Master)[tempdb]>insert into t1 values(1,
    -> 'xuputi','http://blog.csdn.net/leshami');

(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000001 |   1362104 |
| node233-binlog.000002 |      1331 |
| node233-binlog.000003 |       217 |
| node233-binlog.000004 |      7513 |
| node233-binlog.000005 |       490 |
+-----------------------+-----------+

--清理binlog
(root@Master)[tempdb]>purge binary logs to 'node233-binlog.000005';
Query OK, 0 rows affected (0.01 sec)

(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000005 |       490 |
+-----------------------+-----------+

--此时可以看到相应的gtid_purged值
(root@Master)[tempdb]>show variables like '%gtid_purged%';
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| gtid_purged   | 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101 |
+---------------+--------------------------------------------+

--下面启动从库
(root@Slave)[tempdb]>start slave;
Query OK, 0 rows affected (0.00 sec)

--从库状态提示有日志被purged
(root@Slave)[tempdb]>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: Master
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: node233-binlog.000004
          Read_Master_Log_Pos: 7121
               Relay_Log_File: node245-relay-bin.000003
                Relay_Log_Pos: 3133
        Relay_Master_Log_File: node233-binlog.000004
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
                    ...............
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:
                'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, 
                 but the master has purged binary logs containing GTIDs that the slave requires.'
                       ..................
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,
                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4
                Auto_Position: 1

-- 从库上gtid_purged参数,此时为75
(root@Slave)[tempdb]>show variables like '%gtid_purged%';
+---------------+-------------------------------------------+
| Variable_name | Value                                     |
+---------------+-------------------------------------------+
| gtid_purged   | 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-75 |
+---------------+-------------------------------------------+                

--停止从库
(root@Slave)[tempdb]>stop slave;
Query OK, 0 rows affected (0.01 sec)

--下面尝试使用gtid_purged进行跳过事务,,如下,提示仅仅当GLOBAL.GTID_EXECUTED为空才能被设置
(root@Slave)[tempdb]>set global gtid_purged = '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101';
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

--如下查看,已经存在被执行的gtid,即gtid_executed肯定是不为空,且这些gtid记录在从库的binary log中
(root@Slave)[tempdb]>show global variables like '%gtid_executed%'\G
*************************** 1. row ***************************
Variable_name: gtid_executed
        Value: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,
               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4
*************************** 2. row ***************************
Variable_name: gtid_executed_compression_period
        Value: 1000

--下面我们在从库上reset master,即清空从库binlog
(root@Slave)[tempdb]>reset master;
Query OK, 0 rows affected (0.05 sec)

--再次查看gtid_executed已经为空值
(root@Slave)[tempdb]>show global variables like '%gtid_executed%'\G
*************************** 1. row ***************************
Variable_name: gtid_executed
        Value: 
*************************** 2. row ***************************
Variable_name: gtid_executed_compression_period
        Value: 1000

--此时再次设置gtid_purged的值
(root@Slave)[tempdb]>set global gtid_purged = '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101';
Query OK, 0 rows affected (0.01 sec)

--启动从库
(root@Slave)[tempdb]>start slave;
Query OK, 0 rows affected (0.03 sec)

--提示有重复记录,如下所示
--是由于我们在从库停止期间delete这个事务没有被从库的relay log接受到
--其次主从的binlog又被purged,而且从库启动后,执行了gtid_purged,因此主库上新增的记录在从库上提示主键重复
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: Master
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: node233-binlog.000005
          Read_Master_Log_Pos: 490
               Relay_Log_File: node245-relay-bin.000004
                Relay_Log_Pos: 417
        Relay_Master_Log_File: node233-binlog.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
                ................
               Last_SQL_Error: Could not execute Write_rows event on table tempdb.t1; 
 Duplicate entry '1' for key 'PRIMARY', Error_code: 1062;
 handler error HA_ERR_FOUND_DUPP_KEY; the event's master log node233-binlog.000005, end_log_pos 459
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100:102
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101
                Auto_Position: 1

--在从库上删除id为1的记录
(root@Slave)[tempdb]>delete from t1 where id=1;
Query OK, 1 row affected (0.05 sec)

--启动从库的sql_thread线程
(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

--再次查看正常
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: Master
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: node233-binlog.000005
          Read_Master_Log_Pos: 490
               Relay_Log_File: node245-relay-bin.000004
                Relay_Log_Pos: 713
        Relay_Master_Log_File: node233-binlog.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

--上面的这个示例,主要是演示我们使用gtid_purged方式来达到跳过事务的目的
--事实上,主从的数据已经不一致了,应根据实际的需要考虑是否进行相应的修复

 

使用GTID跳过错误的方法:找到错误的GTID跳过(通过Exec_Master_Log_Pos去binlog里找GTID,或则通过上面监控表replication_applier_status_by_worker找到GTID,也可以通过Executed_Gtid_Set算出GTID),这里使用监控表来找到错误的GTID。找到GTID之后,跳过错误的步骤

 

五、小结

1、GTID是全局事务ID,简化了主从架构的部署使得从库不再需要关心log_file和log_pos 
2、由于事务ID的唯一性,使得将其他从库的GTID应用到其它从库成为可能,即提供了便利的failover 
3、GTID是连续的,非空洞性的,因此,对于冲突的情形,需要注入空的事务来实现 
4、可以通过配置延迟从来避免主库上意外的删除对象导致的人为错误

mysql> stop slave; #停止同步
Query OK, 0 rows affected (0.02 sec)

mysql> set @@session.gtid_next='9e2c7c0f-0908-11e7-8230-000c29ab7544:1';  #跳过错误的GTID
Query OK, 0 rows affected (0.00 sec)

mysql> begin; #提交一个空事务,因为设置gtid_next后,gtid的生命周期就开始了,必须通过显性的提交一个事务来结束,否则报错:ERROR 1790 (HY000): @@SESSION.GTID_NEXT cannot be changed by a client that owns a
Query OK, 0 rows affected (0.00 sec)

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

mysql> set @@session.gtid_next=automatic; #设置回自动模式  
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

从复制报错来看,如下,说的是:Can’t find record in ‘user’ ****

再次确认slave同步状况

  Last_Errno: 1032
  Last_Error: Could not execute Update_rows event on table mysql.user; Can't find record in 'user', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;inlog.000002, end_log_pos 744
  Skip_Counter: 0
  Exec_Master_Log_Pos: 154
mysql> show slave status\G;

然后使用mysqlbinlog 解析主库上的binlog信息
如下是执行mysqlbinlog –no-defaults -v -v –base64-output=DECODE-ROWS
binlog.000002 的结果

图片 6图片 7

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

mysql> exit
Bye
[root@tencent01 mysql8000binlog]# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS binlog.000002
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#180523 17:26:57 server id 8000  end_log_pos 123 CRC32 0x7a72d0c2       Start: binlog v 4, server v 5.7.20-log created 180523 17:26:57 at startup
ROLLBACK/*!*/;
# at 123
#180523 17:26:57 server id 8000  end_log_pos 154 CRC32 0x1e585b38       Previous-GTIDs
# [empty]
# at 154
#180523 17:27:08 server id 8000  end_log_pos 219 CRC32 0xcf9ed3c3       GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'/*!*/;
# at 219
#180523 17:27:08 server id 8000  end_log_pos 287 CRC32 0x5ca28a69       Query   thread_id=5     exec_time=0     error_code=0
SET TIMESTAMP=1527067628/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=45/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 287
#180523 17:27:08 server id 8000  end_log_pos 459 CRC32 0xf4845b1b       Table_map: `mysql`.`user` mapped to number 4
# at 459
#180523 17:27:08 server id 8000  end_log_pos 744 CRC32 0x74306d73       Update_rows: table id 4 flags: STMT_END_F
### UPDATE `mysql`.`user`
### WHERE
###   @1='localhost' /* STRING(180) meta=65204 nullable=0 is_null=0 */
###   @2='root' /* STRING(96) meta=65120 nullable=0 is_null=0 */
###   @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @4=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @5=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @6=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @7=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @10=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @11=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @12=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @13=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @14=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @15=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @16=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @17=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @18=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @19=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @20=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @21=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @22=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @23=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @24=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @25=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @26=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @27=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @28=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @29=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @30=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @31=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @32=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @33='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @34='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @35='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @36=0 /* INT meta=0 nullable=0 is_null=0 */
###   @37=0 /* INT meta=0 nullable=0 is_null=0 */
###   @38=0 /* INT meta=0 nullable=0 is_null=0 */
###   @39=0 /* INT meta=0 nullable=0 is_null=0 */
###   @40='mysql_native_password' /* STRING(192) meta=65216 nullable=0 is_null=0 */
###   @41='' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
###   @42=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @43=1527067612 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
###   @44=NULL /* SHORTINT meta=0 nullable=1 is_null=1 */
###   @45=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### SET
###   @1='%' /* STRING(180) meta=65204 nullable=0 is_null=0 */
###   @2='root' /* STRING(96) meta=65120 nullable=0 is_null=0 */
###   @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @4=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @5=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @6=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @7=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @10=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @11=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @12=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @13=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @14=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @15=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @16=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @17=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @18=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @19=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @20=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @21=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @22=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @23=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @24=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @25=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @26=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @27=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @28=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @29=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @30=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @31=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @32=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @33='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @34='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @35='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @36=0 /* INT meta=0 nullable=0 is_null=0 */
###   @37=0 /* INT meta=0 nullable=0 is_null=0 */
###   @38=0 /* INT meta=0 nullable=0 is_null=0 */
###   @39=0 /* INT meta=0 nullable=0 is_null=0 */
###   @40='mysql_native_password' /* STRING(192) meta=65216 nullable=0 is_null=0 */
###   @41='*81F5E21E35407D884A6CD4A731AEBFB6AF209E1B' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
###   @42=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @43=1527067612 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
###   @44=NULL /* SHORTINT meta=0 nullable=1 is_null=1 */
###   @45=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
# at 744
#180523 17:27:08 server id 8000  end_log_pos 813 CRC32 0xd3a07e78       Query   thread_id=5     exec_time=0     error_code=0
SET TIMESTAMP=1527067628/*!*/;
COMMIT
/*!*/;
# at 813
#180523 17:27:08 server id 8000  end_log_pos 878 CRC32 0x6451705b       GTID    last_committed=1        sequence_number=2       rbr_only=no
SET @@SESSION.GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:2'/*!*/;
# at 878
#180523 17:27:08 server id 8000  end_log_pos 965 CRC32 0x7451238c       Query   thread_id=6     exec_time=0     error_code=0
SET TIMESTAMP=1527067628/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=45/*!*/;
SET @@session.time_zone='SYSTEM'/*!*/;
flush privileges
/*!*/;
# at 965
#180523 17:27:08 server id 8000  end_log_pos 988 CRC32 0x108e7f09       Stop
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@tencent01 mysql8000binlog]#
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.206.140
                  Master_User: u_repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 499
               Relay_Log_File: localhost-relay-bin.000004
                Relay_Log_Pos: 454
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_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: 499
              Relay_Log_Space: 2024
              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: 140
                  Master_UUID: 9e2c7c0f-0908-11e7-8230-000c29ab7544
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 9e2c7c0f-0908-11e7-8230-000c29ab7544:1-2
            Executed_Gtid_Set: 347cbac6-0906-11e7-b957-000c2981a46e:1,
9e2c7c0f-0908-11e7-8230-000c29ab7544:1-2,
c59a2526-08fd-11e7-a5c7-000c296f2953:1-2
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

ERROR: 
No query specified

不难理解,在master安装之后,第一时间修改了root的密码,那么修改root密码应该是第一个事务,
因此到了slave上,第一个事务就是无法执行的,为什么系统表(mysql.user)不允许复制事务?这一点先抛开,
如何在binlog中确认是哪一个事务Id?
上面说的是 Exec_Master_Log_Pos: 154,end_log_pos
744,也就是在这个偏移量之间的事务是导致slave无法复制的,这个事务Id正式1,也即GTID_NEXT=
‘6d257f5b-5e6b-11e8-b668-5254003de1b6:1’
这里涉及利用Exec_Master_Log_Pos和end_log_pos
找事物Id的问题,从名字大概能猜到是这两个偏移量之间的一个事物Id
这两个偏移量之间的事物Id,也就是
‘6d257f5b-5e6b-11e8-b668-5254003de1b6:1’
笔者一开始是找end_log_pos
744后面的事物Id,也即事物2,然后在从库设置跳过,怎么也不行。

View Code

 

打完收工

对于数据冲突之列的复制错误,至于跳过事物Id本身,就不复杂了。

本文地址:

(1)停止slave进程
mysql> STOP SLAVE;
(2)设置事务号,事务号从Retrieved_Gtid_Set获取
在session里设置gtid_next,即跳过这个GTID
mysql> SET GTID_NEXT= ‘6d257f5b-5e6b-11e8-b668-5254003de1b6:1’
(3)设置空事物
mysql> BEGIN; COMMIT;
(4)恢复事物号
mysql> SET SESSION GTID_NEXT = AUTOMATIC;
(5)启动slave进程
mysql> START SLAVE;
跳过一个事务之后,重启slave,恢复正常

图片 8

 稍等几秒钟,从库很快就追上主库了

图片 9

学而不思则罔,思而不学则殆。更多的时候是需要大胆去尝试,去折腾,在慢慢回味其中的道理,掌握了理论,动手试一遍,就大概清楚了。

 

 对于跳过MySQL主从复制的一些总结:

经常遇到不同的复制错误,通过show slave
status的结果,通常是看是slave_io_running和slave_sql_running来判断slave复制是否正常。
之前总是纠结slave_io_running为NO的时候,怎么怎么办,slave_sql_running为NO的时候怎么怎么办,
然后上网查出来各种攻略或者解决办法,答案可谓是五花八门,运气好一下子就解决了,运气不好,怎么也解决不了,类似的问题还会出现。

如果结合原理,不管是哪种复制方式,其实根本不用上网上查各种五花八门的解决办法,自己认真分析一下,原因大概就猜个差不多了。

1,对于slave_io_running为NO的情况:
首先要想,slave_io_running线程是干嘛的?连接至master
往slave机器上拉master机器上的binlog的啊,那么,如果当slave_io_running为NO的时候,原因是什么?
肯定是slave连不上master了,slave连不上master原因又是什么呢?
无外乎用户复制的账号权限不足、slave与master之间的网络不通、change
master的时候密码写错了、端口号写错了等等原因都有可能,
需要自己有目标地去排查,而不是上来就上网搜,一种一种办法尝试,别人的问题可能有别人的原因,尝试用别人的办法解决自己的问题,不一定总是凑效的。

2,对于slave_sql_running为NO的情况:
首先要想,slave_sql_running线程是干嘛的?是解析slave_io_running下载过来的master上的binlog的,
如果slave_io_running为YSE,slave_sql_running为NO,也就是说binlog传输过来了,解析过程出错了
哪又是什么原因?也无外乎是master上的日志无法应用到slave上,
此时分为两种情况,举个例子,如下截图,last_error
中也写的很清楚了,err_key_not_found
那就是说说在应用master上一个事物的binlog的时候,slave找不到对应的数据,至于解决办法先不说,最主要的是找到真正的原因。,

3,最后猜测一种情况:
初始化复制的时候,会不会出现slave_io_running为NO,slave_sql_running为YSE的情况?
我想是不会的,slave_io_running是下载(传输)master的binlog的,slave_sql_running是解析下载过来binlog的,怎么可能会出现master的binlog都没有下载过来,slave能够正常解析binlog呢?

上述错误是主从复制的第一种错误,意思说应用某一条事物的时候出现了错误
另一种是主库上binlog日志被清理(比如过期自动情况等等),
从库在执行主库的事物Id的时候找不到master上的binlog(对应的错误信息是Got
fatal error 1236 from master when reading data from binary log:)
两种错误,是两种不同的解决办法,虽然说都是跳过错误日志,但是跳跟跳还是不太一样的
gtid跳过复制错误的方法:

对于第一种错误,说明从库在应用当前事物Id的时候出错了,从库上无法应用某一个事物编号,数据要跳过一个错误,正常操作如下:

stop slave;
set gtid_next='6d257f5b-5e6b-11e8-b668-5254003de1b6:n';
begin;
commit;
set gtid_next='AUTOMATIC';
start slave;

对于master上的binlog被清理,slave上找不到对应的binlog,需要跳过主库上所有被清理的binlog,
在主库执行show variables like
‘%gtid_purged%’,看主库清理的日志的范围,比如:6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578
那么就要跳过主库上被清理的binlog的范围,需要设置从库上的gtid_purged的范围即可

stop slave;
reset master;
set global gtid_purged='6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578';
start slave;

有上述两种处理方式来看,不同的错误需要不同的处理方式,如果弄清楚了背后的原理,其实,问题并不难解决。

所有的问题,都需要具体分析其原因,然后找到其解决方案,这其中,都依赖于事物背后的原理,因此说,学习某种技术,要首选弄清楚其背后的原理,才是根本。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图