1.巴黎人手机版:跳过指定数量的事务,找不到对
分类:巴黎人-数据库

STOP SLAVE 'slave_account';
SET @@default_master_connection = 'slave_account';
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE 'slave_account';
SET @@default_master_connection = '';

跳过错误有两种方式:
1.跳过指定数量的事务:
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1        #跳过一个事务
mysql>slave start

MySQL GTID复制错误处理之跳过错误,mysqlgtid

某Slave报错信息:

mysql> show slave statusG;

巴黎人手机版 1

mysql> show slave statusG;
*************************** 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

View Code

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

mysql> select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER=1007G

巴黎人手机版 2

mysql> select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER=1007G
*************************** 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)

View Code

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

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)

再次确认slave同步状况

mysql> show slave statusG;

巴黎人手机版 3

mysql> show slave statusG;
*************************** 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

View Code

打完收工

本文地址:

GTID复制错误处理之跳过错误,mysqlgtid 某Slave报错信息: mysql show slave statusG; mysql show slave statusG; *************************** 1 . row **********...

这里稍微提一下:mariadb 的Gtid 错误,我们可以采用参数sql_slave_skip_counter=N直接跳过,但是,却不支持使用pt-slave-restart 跳过错误,而且mariadb 的Gtid 和官方不通用,实现原理相同,实现方法缺不同,所以我们也不能用这两个版本之间搭建gtid主从。

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

mysql 的主从错误跳过和mariadb的多源主从复制错误跳过操作不同,请注意:
更改会话的default_master_connection变量

2.修改mysql的配置文件,通过slave_skip_errors参数来跳所有错误或指定类型的错误
vi /etc/my.cnf
[mysqld]
#slave-skip-errors=1062,1053,1146 #跳过指定error no类型的错误
#slave-skip-errors=all #跳过所有错误

今天我们主要看主从模式下,几种跳过错误的方法,跳过事务,还是跳过event?这个在之前其实我们一直都是忽略的,这在我们维护主从过程中,很容易就导致主从数据更大的不一致。
测试机器5.7.18 主从 gtid 开启
主库数据
巴黎人手机版 4
从库数据
巴黎人手机版 5
很明显主从数据有一个不一直的地方,从库少了一条(28,2) 的数据。这个时候主库开启以下事务:
巴黎人手机版 6
这必然导致从库出现错误,报1032错误,如下所示:
mysql> show slave statusG;
***1. row***
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.56
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000023
Read_Master_Log_Pos: 1928
Relay_Log_File: hadoop2-relay-bin.000012
Relay_Log_Pos: 1595
Relay_Master_Log_File: mysql-bin.000023
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: 1032
Last_Error: Could not execute Delete_rows event on table yhtest1.yhtest; Can't find record in 'yhtest', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000023, end_log_pos 1812
Skip_Counter: 0
Exec_Master_Log_Pos: 1502
Relay_Log_Space: 2384
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: 1032
Last_SQL_Error: Could not execute Delete_rows event on table yhtest1.yhtest; Can't find record in 'yhtest', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000023, end_log_pos 1812
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: ab8c3ec3-b588-11e7-a769-000c29c57be6
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: 171130 23:55:18
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: ab8c3ec3-b588-11e7-a769-000c29c57be6:96-101
Executed_Gtid_Set: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-100,
b6ddfda0-d8bc-4272-a58f-4ea75acbbc79:1-22:1000012-1000013:2000012-2000013,
d24c1c76-b4ef-11e7-969a-000c29a75f68:1-17
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.01 sec)

不难理解,在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,然后在从库设置跳过,怎么也不行。

解决方法:
方法1
5.7下,由于开启了GTID ,不能通过参数sql_slave_skip_counter=N 跳过错误,但是我们可以通过在从库执行空事物的方法,跳过该错误,但要注意,这样跳过的是一个事物。
从以上报错信息中,我们很容易看出目前执行位置在: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-100 也就是报错位置在: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-101
操作如下:
巴黎人手机版 7
这个时候,我们再次show slave statusG 看到主从已经恢复正常,但是我们再对比数据,发现我们刚才主库的三个event 在同一个事件中,被我们全部跳过了,也就是两个插入数据也没有在从库执行!
主库数据:
巴黎人手机版 8
从库数据:
巴黎人手机版 9

 

方法2
如果我们觉得以上方法步骤比较多,还可以借住与pt-slave-restart 来进行主从错误跳过,跳过方法如下:
巴黎人手机版 10
这个同样可以达到跳过主从错误的目的!但是其跳过的单位也是事务,同样也会导致主库所做的两个插入没有在从库执行!
方法3
利用slave_exec_mode参数来处理主从中遇到的错误,操作步骤如下:

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]#

stop slave;
set global slave_exec_mode='IDEMPOTENT'; 幂等模式 (默认是STRICT严格模式)
start slave;
查看主从数据
巴黎人手机版 11
发现一致了,也就是说在调整参数slave_exec_mode后,我们跳过的delete 错误,但是两个插入操作任然是执行的,同时,查看错误日志,我们发现记录如下:
巴黎人手机版 12
方法4
利用参数slave_skip_errors跳过错误,操作方法如下,在配置文件中添加slave_skip_errors=1062,1032 等,重启数据库,启动slave ,也会发现测试结果和方法3一致。但是 slave_skip_errors 不支持动态修改!
方法5
从库1032时,我们直接去主库找到对应的记录,插入到从库当中,restart salve, 1062 时 我们直接在从库中备份删除掉冲突记录即可。

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

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

 

本文说的是第一种错误。

本文由巴黎人手机版发布于巴黎人-数据库,转载请注明出处:1.巴黎人手机版:跳过指定数量的事务,找不到对

上一篇:没有了 下一篇:没有了
猜你喜欢
热门排行
精彩图文