MySQL主从不一致发现的细小问题分析(r12笔记第63天)

   今天和同事一起看了一个问题,她在一个主从环境中发现了数据不一致,存在主键冲突。

    show slave status的报错信息大概是下面的样子。

Last_Error: Coordinator stopped because there were error(s) in the
worker(s). The most recent failure being: Worker 0 failed executing
transaction '0e454161-3169-11e7-98f6-02004d9d000a:665' at master log
mysql-bin.000001, end_log_pos 274391. See error log and/or
performance_schema.replication_applier_status_by_worker table for more
details about this failure or others, if any.      这是一个MySQL 5.7版本的主从环境,还没有投入线上业务使用,是在搭建的过程中碰到了这类问题。

    一般来说,如果主从数据不一致,可以使用pt工具来尝试检查和修复。而这个问题是在搭建主从的时候出现,主从搭建貌似也没有太多的技巧,开启GTID,完全够用了,听起来确实有些奇怪。

    同事在使用pt工具修复失败之后,准备重建,但是重建的过程也很曲折,slave总是会有主键数据的冲突。我们检查了主库端,数据是没有冲突的,难道这又是bug,我觉得细细看看。

     我拿到环境,准备向从搭建从库突破,因为数据量不大,所以我重新导入了一次数据,是使用最简单的重定向方式来导入。

# mysql -pxxxxx < db-dump-201705121718.sql
Logging to file '/home/mysql/query.log'
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.  但是我运行之后发现,导入的时候报错了,在导出的时候其实可以加一个选项,这样就不会有这类干扰了。

  因为是重新搭建从库,所以我使用了reset master的方式,

> reset master;
Query OK, 0 rows affected (0.01 sec)  再次导入就没有问题了。

  接下来就是change master的设置.

CHANGE
MASTER TO       MASTER_HOST='xxxx',       
MASTER_USER='rep_user',        MASTER_PASSWORD='xxxx',       
MASTER_PORT=3306,        MASTER_AUTO_POSITION = 1;
  启动slave后发现同事碰到的错误没有了。

  对于这个问题,我们进行了沟通,同事导入的时候使用source的方式导入,说没有看到错误,我们对比了一下搭建方法,也就这个地方不同了。

   带着试试看的态度,我使用source的方式搭建了一次。

>source db-dump-201705121718.sql   看到后台输出了很多的日志,总体来看是没有什么异常的地方。然后重启slave错误可以重现了。所以通过这个过程可以基本断定和bug无关。

  这个时候我们的关注点逐步缩小,经过论证,就是这个地方的问题,我们来通过几个小测试来说明。

  我写了几行SQL,文件a.sql包含创建表,插入两行数据的操作。

# cat a.sql
create table test(id int);
insert into test values('aaa');
insert into test values(100);使用mysql test < a.sql 还是source的方式都没有任何报错。

运行后表test的数据为:

> select *from test;
+------+
| id   |
+------+
|    0 |
|  100 |
+------+这一点确实让我有些意外。当然问题的重点不在这里,我们继续改一下脚本。

# cat a.sql
create table test(id int);
insert into test values('aaa','aa');
insert into test values(100);这个时候差别就很明显了。

# mysql test < a.sql
Logging to file '/home/mysql/query.log'
ERROR 1136 (21S01) at line 2: Column count doesn't match value count at row 1查看数据情况,是没有数据插入的。

> select *from test;
Empty set (0.00 sec) 而使用source的方式,日志如下:

> source a.sql
Query OK, 0 rows affected (0.01 sec)
ERROR 1136 (21S01): Column count doesn't match value count at row 1
Query OK, 1 row affected (0.01 sec)查看数据,是有1行数据的。

所以很大的一个差别就在于此,使用重定向的方式,如果有错误会直接退出,而使用source会依次执行,错误的地方跳过,继续执行下面的步骤。这样一个细小的地方可谓是细思恐极。对于我们做数据变更类的操作而言,是尤其重要的。

时间: 2024-10-23 08:53:52

MySQL主从不一致发现的细小问题分析(r12笔记第63天)的相关文章

MySQL主从不一致的修复过程

昨天发现一个5.7的MySQL从库在应用日志的时候报出了错误.从库启用过了并行复制.Last Error的内容为: Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649' a

MySQL频繁停库的问题分析(r12笔记第33天)

  最近也抽空帮一些网友解决一些问题,有些是Oracle,有些是MySQL,有时候虽然忙忙乎乎,但是解决问题之后还是很有成就感的.   今天来说一个蛮有意思的问题,听起来还很诡异.是一个网友向我咨询,看看能不能给出一些建议.当我看到日志,隐隐感觉这是一个bug的感觉. 详细的日志如下: 2017-04-13 16:25:29 40180 [Note] Server socket created on IP: '::'. 2017-04-13 16:25:29 40180 [Warning] St

MySQL中的double write(二)(r12笔记第17天)

    MySQL里的double write是InnoDB的三大闪亮特性,另外两个是insert buffer 和自适应哈希,其实还有几个比如异步IO,Flush neighbour Page(刷新邻接页),这个和系统层面的关联性较高,所以三大亮点还是更有针对性的.    当然一说到MySQL里的double write,其实主要是要应对一个很自然的问题,那就是partial write. 经典的partial write问题    这个问题比较经典,很多数据库设计中都需要考虑到这样一个临界点

一个ORA-00600问题的简单分析(r12笔记第18天)

  在前些天尝试使用sysbench来压测Oracle,没想到初战就不顺利,因为初始化几百万数据库,竟然一个小时过去了,一个表的数据都没有初始化好,这个可让我大大失望,所以我就强制清理了会话,把数据初始化流程给终止了.    今天想继续试试,看看能不能优化一些地方.但是刚开始跑初始化数据的脚本的时候,就抛出了一个ORA-00600的错误. 错误信息如下: Creating table 'sbtest1'... FATAL: OCIStmtExecute failed in drv_oracle.

Oracle数据库端口突然无法访问的分析(r12笔记第46天)

 最近碰到一个蛮有启发意义的案例.是数据库监听相关的,但是实际的原因却又出乎意料.  问题的反馈受益于开发同学,一个开发同学在lync上找到我,说现在一个线上业务的数据库访问有些问题,想问问我是否有什么建议.大体了解了下,他们在使用一个非1521的端口,比如端口是1525,他们在业务端看到的错误信息类似下面的样子: java.sql.SQLException: Io exception: The Network Adapter could not establish the connection

MySQL 5.6, 5.7并行复制测试(r12笔记第9天)

   对于主从延迟,其实一直以来就是一个颇有争议的话题,在MySQL阵营中,如果容忍一定的延迟的场景,通过主从来达到读写分离是个很不错的方案,但是延迟率到底有多高可以接受,新版本中的并行复制效果怎么样,在不同的版本中是否有改变,我们能否找到一些参考的数据来佐证,这一点上我们可以通过一些小测试来说明.    首先来为了基本按照同一个参考标准,我们就在同一台服务器上安装了5.6,5.7的MySQL服务,另外一台服务器上搭建了从库.    数据库版本为5.6.23 Percona分支, 5.7.17

MySQL中的批量初始化数据的对比测试(r12笔记第71天)

  一直以来对于MySQL的存储过程性能还是颇有微词的,说实话够慢的.有时候想做一些对比测试,存储过程初始化几万条数据都得好一会儿,这功夫Oracle类似的测试早都做完了,今天就赶个晚班车,把这个没做完的任务完成了.     我大体测试了一下,以100万数据为基准,初始化性能的提升会从近8分钟提升到10多秒钟.      我自己尝试了以下4种方案.      1.存储过程批量导入(近8分钟)      2.存储过程批量导入内存表,内存表导入目标表(近5分钟)      3.使用shell脚本生成

分分钟搭建MySQL Group Replication测试环境(二)(r12笔记第41天)

   之前总结过一篇,是分分钟搭建MySQL MGR环境的,但是有一个地方还有待改善,那就是那个脚本仅仅支持single-primary模式,不支持多主模式,而官方文档中这部分信息还比较少.    我觉得这部分内容一方面和本身MGR的多主支持还不够成熟也有关系,需要一个过渡.但是如果想测试测试也是完全可以的,所以我决定改进我的脚本.    大体来说,如果要开启多主模式,如果能够轻松搭建出单主,读写分离的架构,那么搭建多主是很简单的一件事情. 在原来单主模式的主节点执行操作如下: stop GRO

使用pt工具检测MySQL主从延迟(r12笔记第7天)

 今天翻看了下<高性能MySQL>,真是让人拍手称绝,里面的很多实战思路非常不错,各种问题分析如数家珍,如果是有一定基础的同学,看起来会非常不错.    当然里面提到的一个地方,感觉很有意思,那就是主从延迟的一个测算思路.书中他们是通过建立一张表,插入时间相关的数据,值得一提的是这个表的存储引擎是Federated,主要就是为了完成类似Oracle DB link一样的特殊需求,在备库端来对比这个时间差来得到一个相对精准的延迟值.    当然有的同学可能会说,我们有show slave sta