专栏首页DBA随笔MySQL复制问题的三个参数介绍

MySQL复制问题的三个参数介绍

01

MySQL复制问题的三个参数介绍

今天星期二,早上居然起晚了,上班迟到了,简直是。。。废话不多说,在昨天的文章中,我们提到了三个参数,分别是:

slave_exec_mode参数;

sql_slave_skip_counter=N参数;

slave-skip-errors=N参数。

这三个参数都可以解决并行复制中的一些指定的错误,例如duplicate key 1062错误等,今天我们简单试验一下,这三个参数的区别:

01

sql_slave_skip_counter参数

这个参数的设置主要是为了跳过某些错误的"event",注意这里的用词是event而不是事务,是因为它的本质是跳过一个一个事件,需要注意的是,这个参数需要在偏移量复制模式中使用,如果使用的是gtid的复制模式,则不可以使用这个参数。我们来看例子,首先搭建一套复制关系:

master 10.30.124.68

slave 10.30.124.128

这俩实例互为主从。我们创建测试表test.yeyz,并插入一些数据,其中id为主键,具有唯一性,如下:

master上

mysql:(none) 22:25:56>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
+----+------+
4 rows in set (0.00 sec)

slave上

mysql:(none) 22:25:38>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec)

我们可以发现,从节点的数据比主节点多一条,多了id=5的记录,然后我们在主节点上插入数据:

mysql:(none) 22:26:06>>insert into test.yeyz values (5,5),(6,6);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

此时观察从节点:

mysql:(none) 22:26:34>>show slave status\G
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 523
               Relay_Log_File: slave-relay-bin.000002
                Relay_Log_Pos: 319
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
                   Last_Errno: 1062
                   Last_Error: Coordinator stopped because there were error(s) 
in the worker(s). The most recent failure being:
 Worker 0 failed executing transaction 'ANONYMOUS' at
 master log mysqlbin.000002, end_log_pos 492.
 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

可以发现,从节点已经SQL线程断开了, 这个时候,在主节点上查询这个错误position 492处的binlog,可以看到:

mysql:(none) 22:30:28>>show binlog events in 'mysqlbin.000002' from 194;  
+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+
| Log_name        | Pos | Event_type     | Server_id | End_log_pos | Info                                       |
+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+
| mysqlbin.000002 | 194 | Anonymous_Gtid |       192 |         259 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'       |
| mysqlbin.000002 | 259 | Query          |       192 |         327 | BEGIN                                      |
| mysqlbin.000002 | 327 | Rows_query     |       192 |         391 | # insert into test.yeyz values (5,5),(6,6) |
| mysqlbin.000002 | 391 | Table_map      |       192 |         439 | table_id: 108 (test.yeyz)                  |
| mysqlbin.000002 | 439 | Write_rows     |       192 |         492 | table_id: 108 flags: STMT_END_F            |
| mysqlbin.000002 | 492 | Xid            |       192 |         523 | COMMIT /* xid=38 */                        |
+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+
6 rows in set (0.00 sec)

从上面的binlog可以看出来,我们的一个insert操作实际上生成了5个enent,分别对应的pos是从259~492,关于event,待会儿再说。

因为主节点上插入了id=5的记录,跟从节点上的记录冲突了,查看错误日志,可以发现:

Duplicate entry '5' for key 'PRIMARY',
 Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
the event's master log FIRST, 
end_log_pos 492 | 2019-07-16 22:26:25

我们通过sql_slave_skip_counter参数的设置来解决这个问题,步骤如下:

mysql:(none) 22:29:32>>stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql:(none) 22:32:45>>set global sql_slave_skip_counter=1;
Query OK, 0 rows affected (0.00 sec)

mysql:(none) 22:33:06>>start slave;

在昨天的文章中我们说过,sql_slave_skip_counter后面跟的值是event的个数,所以这里我们相当于跳过了一个event,mysql中规定,如果跳过一个event之后,还在某一个事务里面,那么会继续跳过这个事务。

使用这个参数跳过一个event之后,我们再来看从库表中的数据和复制情况,可以看到:

slave表:

mysql:(none) 22:33:10>>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 523
               Relay_Log_File: slave-relay-bin.000003
                Relay_Log_Pos: 319
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes


mysql:(none) 22:33:16>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
+----+------+
5 rows in set (0.00 sec)

看看master表:

mysql:(none) 22:33:36>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
+----+------+
6 rows in set (0.00 sec)

可以发现,master中数据插入成功,而slave中数据插入失败,也就是说:

该参数跳过错误的时候,会导致主从的数据不一致。

02

slave_skip_errors参数

这个参数是跳过制定的错误,也就是说,需要我们设置对应的error_code,从下面的日志中的内容可以看出,error_code的值为1062

Duplicate entry '5' for key 'PRIMARY',
 Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
the event's master log FIRST, 
end_log_pos 492 | 2019-07-16 22:26:25

我们需要手动将这个参数的值也该为1062,需要注意的是,这个参数的改动需要重启mysql服务,因为这个参数是一个只读的参数。

修改后的情况如下:

mysql--dba_admin@127.0.0.1:(none) 22:38:55>>show variables like '%errors%';
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_connect_errors | 1000000 |
| slave_skip_errors  | 1062    |
+--------------------+---------+
2 rows in set (0.01 sec)

此时我们更新master表和slave表的数据,更新后的情况如下:

master:

mysql:(none) 22:39:15>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 ||  2 |    2 |
|  3 |    3 ||  4 |    4 |
|  5 |    5 ||  6 |    6 |
+----+------+
6 rows in set (0.00 sec)

slave上:

mysql:(none) 22:40:15>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
+----+------+
7 rows in set (0.00 sec)

我们发现,slave表比master表多一条数据,也就是id=7的记录,此时我们在master上执行:

mysql:(none) 22:34:15>>insert into test.yeyz values (7,7),(8,8);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

查看slave上面的复制情况和数据情况,如下:

mysql:(none) 22:39:05>>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 852
               Relay_Log_File: slave-relay-bin.000005
                Relay_Log_Pos: 648
        Relay_Master_Log_File: mysqlbin.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: 


mysql:(none) 22:40:15>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
+----+------+
7 rows in set (0.00 sec)

可以看到,复制没有出现错误,即使从库上已经有id=7的记录。而且发现,从库的数据跟之前保持一致,也就是说,主库插入的id=8的记录没有被同步过来。

总结一下:该参数在跳过复制错误的时候,需要重启mysql服务,然后可能导致主从数据不一致。

03

slave-skip-errors=N参数

再看最后一个参数,这个参数表示的是并行复制过程中的从库复制模式,默认值是strict严格模式,和上面一样,我们先看主库和从库的数据情况:

master数据:

mysql:(none) 22:39:20>>select * from test.yeyz;                 
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
|  8 |    8 |
+----+------+
8 rows in set (0.00 sec)

slave数据:

mysql:(none) 22:42:46>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
|  8 |    8 |
|  9 |    9 |
+----+------+
9 rows in set (0.00 sec)

此时我们在从库上修改参数如下:

mysql:(none) 22:42:59>>show variables like '%exec%';
+----------------------------------+--------+
| Variable_name                    | Value  |
+----------------------------------+--------+
| gtid_executed_compression_period | 1000   |
| max_execution_time               | 0      |
| rbr_exec_mode                    | STRICT |
| slave_exec_mode                  | STRICT |
+----------------------------------+--------+
4 rows in set (0.00 sec)

mysql:(none) 22:44:05>>set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)

mysql:(none) 22:44:10>>show variables like '%exec%';           
+----------------------------------+------------+
| Variable_name                    | Value      |
+----------------------------------+------------+
| gtid_executed_compression_period | 1000       |
| max_execution_time               | 0          |
| rbr_exec_mode                    | STRICT     |
| slave_exec_mode                  | IDEMPOTENT |
+----------------------------------+------------+
4 rows in set (0.00 sec)

修改完参数,我们在主库上进行insert操作:

insert into test.yeyz values (9,9),(10,10);

查看从库的复制状态和数据情况,如下:

mysql:(none) 22:44:14>>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.68
                  Master_User: dba_repl
                  Master_Port: 4306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000002
          Read_Master_Log_Pos: 1183
               Relay_Log_File: slave-relay-bin.000007
                Relay_Log_Pos: 650
        Relay_Master_Log_File: mysqlbin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

1 row in set (0.00 sec)

mysql:(none) 22:44:38>>select * from test.yeyz;
+----+------+
| id | age  |
+----+------+
|  1 |    1 |
|  2 |    2 |
|  3 |    3 |
|  4 |    4 |
|  5 |    5 |
|  6 |    6 |
|  7 |    7 |
|  8 |    8 |
|  9 |    9 |
| 10 |   10 |
+----+------+
10 rows in set (0.00 sec)

可以发现,既没有出现复制错误,主库上插入的数据也同步过来了。

总结一下:

slave_exec_mode参数;

sql_slave_skip_counter=N参数;

slave-skip-errors=N参数。

这三个参数都能解决复制过程中的不一致情况,区别如下:

slave_exec_mode参数可以保证主从数据一致,其他两个不可以。

slave-skip-errors参数可以跳过制定的错误,但是需要重启实例,不能保证数据一致。

sql_slave_skip_counter参数需要在偏移量的复制模式下使用,不能保证数据一致。

本文分享自微信公众号 - DBA随笔(gh_acc2bbc0d447),作者:AsiaYe

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • insert into select加锁规则补充

    形如这样的语句,在statement模式的binlog下,会对B加记录锁和间隙锁,A上会有自增锁;而在row模式下,经过测试,B表上并不会有锁。

    AsiaYe
  • insert语句的加锁情况分析

    今天分享的内容是MySQL里面insert语句的加锁情况,废话就不多说了,直接从线上的例子开始吧。

    AsiaYe
  • show slave hosts的一个问题

    今天早上来公司,查看一个5.5版本的MySQL主从复制的架构的时候,发现一个问题,这个问题之前在5.7版本的MySQL版本中没有遇到过,这里记录一下,...

    AsiaYe
  • python 读取与存储json

    官方文档:http://python3-cookbook.readthedocs.io/zh_CN/latest/c06/p02_read-write_json...

    py3study
  • 人工智能在疾病传播方面的应用

    近期,新型冠状病毒声势浩大,人工智能的作用值得关注。——在控制其他疾病传播方面,算法不仅提供了更好的干预和预防策略,还帮助优化了资源分配,以抗击感染的传播。

    AiTechYun
  • 归并排序 递归版和非递归版的实现(java)

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/gdutxiaoxu/article/details/...

    用户2965908
  • 你所能用到的无损压缩编码(一)

          这个系列将结合C/C++介绍无损压缩编码的实现,正如Charles Petzold在<CODE:Hidden Language of Compute...

    一心一怿
  • 详谈P(查准率),R(查全率),F1值

    怎么来的? 我们平时用的精度accuracy,也就是整体的正确率 acc=predict_right_num/predict_num 这个虽然常用,但...

    zenRRan
  • SpringBoot中使用@Scheduled创建定时任务

    我们在编写SpringBoot应用中经常会遇到这样的场景,比如:我需要定时地发送一些短信、邮件之类的操作,也可能会定时地检查和监控一些标志、参数等。

    JouyPub
  • iPhone 11为何嘴上说真丑,销量却真香? | Alfred数据室

    9月11号早晨,在Steve Jobs剧院举行的2019苹果秋季新品发布会之后,蹲守在发布会前的果粉们开始了自乔布斯去世之后一年一度的对苹果的群嘲。从5S的土豪...

    Alfred数据室

扫码关注云+社区

领取腾讯云代金券