MySQL并行复制的一个坑
早上巡检数据库,发现一个延迟从库的sql_thread中断了。
Last_SQL_Errno: 1755
Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093, position 152912092 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly..
检查performance_schema下的replication_applier_status_by_worker表,除了GTID之外也没有更具体的信息:
"root@localhost:mysql3308.sock [(none)]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| | 1 | NULL | OFF | 0b961fcc-41c2-11e7-84fd-286ed488c7da:156369774 | 0 | | 0000-00-00 00:00:00 |
| | 2 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| | 3 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| | 4 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| | 5 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| | 6 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| | 7 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| | 8 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
既然relay_log的位置信息都有了,那就去日志里看看吧:
解析Binlog文件:
mysqlbinlog -v --base64-output=decode-rows oracle-relay-bin.000093 >1.sql
找到152912092位置点附近的日志:

检查了一下数据库中这个表ID为14816035的数据确实是不存在的。
另外除了这条日志,其它日志的last_committed和sequence_number都为0,last_committed表示事务提交的时候,上次事务提交的编号。last_committed和sequence_number代表的就是所谓的LOGICAL_CLOCK。
猜测如果手动把这条数据插入延迟从库,并且使用注入一个空事务跳过这个GTID的方法重启sql_thread,相信这个错误也能被解决。
但既然带了LOGICAL_CLOCK的事务就会出错,跳过事务的方法很难保证以后不会出错。
注意到这条日志的last_committed是一个异常大的值,且错误信息中有提到The master event is logically timestamped incorrectly。我怀疑是不是并行配置的问题。
从库配置:
"root@localhost:mysql3308.sock [(none)]>show variables like '%para%';
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 8 |
+------------------------+---------------+
再检查主库配置:
(root@localhost:mysql.sock) [(none)]>show variables like '%para%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| slave_parallel_workers | 0 |
+------------------------+-------+
发现主库根本就没有slave_parallel_type这项配置。想起来主库是mysql5.6了。
(root@localhost:mysql.sock) [(none)]>select version();
+------------+
| version() |
+------------+
| 5.6.35-log |
+------------+
那么问题基本上就知道了,主库5.6只支持基于DATABASE的并行复制,而5.7的从库配置成LOGICAL_CLOCK导致了异常。
明白了问题所在,那就好解决了,把从库的slave_parallel_type改为DATABASE,再起sql_thread问题应该就解决了:
"root@localhost:mysql3308.sock [none]>set global slave_parallel_type='DATABASE';
Query OK, 0 rows affected (0.00 sec) "root@localhost:mysql3308.sock [none]>show global variables like '%slave_parallel_type%';
+---------------------+----------+
| Variable_name | Value |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.00 sec) "root@localhost:mysql3308.sock [none]>show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000104
Read_Master_Log_Pos: 160115307
Relay_Log_File: oracle-relay-bin.000093
Relay_Log_Pos: 152912092
Relay_Master_Log_File: binlog.000100
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: 1755
Last_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093, position 152912092 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly..
Skip_Counter: 0
Exec_Master_Log_Pos: 152911925
Relay_Log_Space: 4455094667
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: 1755
Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093, position 152912092 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly..
Replicate_Ignore_Server_Ids:
Master_Server_Id: 50
Master_UUID: 0b961fcc-41c2-11e7-84fd-286ed488c7da
Master_Info_File: mysql.slave_master_info
SQL_Delay: 3600
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 180716 18:02:56
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:111060115-163843604
Executed_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:1-156369774
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec) "root@localhost:mysql3308.sock [none]>stop slave sql_thread;
Query OK, 0 rows affected, 1 warning (0.00 sec) "root@localhost:mysql3308.sock [none]>start slave sql_thread;
Query OK, 0 rows affected (0.01 sec) "root@localhost:mysql3308.sock [none]>show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000104
Read_Master_Log_Pos: 160161836
Relay_Log_File: oracle-relay-bin.000093
Relay_Log_Pos: 169205552
Relay_Master_Log_File: binlog.000100
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: 169205385
Relay_Log_Space: 4455141196
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: 5351
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: 50
Master_UUID: 0b961fcc-41c2-11e7-84fd-286ed488c7da
Master_Info_File: mysql.slave_master_info
SQL_Delay: 3600
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Waiting for Slave Worker to release partition
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:111060115-163843692
Executed_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:1-156400100
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
打完收工。
转载请注明出处。
本文地址:https://www.cnblogs.com/ajiangg/p/9399892.html
MySQL并行复制的一个坑的更多相关文章
- mysql并行复制降低主从同步延时的思路与启示
一.缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重. 为什么mysql主从延时这么大? 回答:从 ...
- [转载自阿里丁奇]各版本MySQL并行复制的实现及优缺点
MySQL并行复制已经是老生常谈,笔者从2010年开始就着手处理线上这个问题,刚开始两三年也乐此不疲分享,现在再提这个话题本来是难免"炒冷饭"嫌疑. 最近触发再谈这个话题,是 ...
- MySQL 并行复制演进及 MySQL 8.0 中基于 WriteSet 的优化
MySQL 8.0 可以说是MySQL发展历史上里程碑式的一个版本,包括了多个重大更新,目前 Generally Available 版本已经已经发布,正式版本即将发布,在此将介绍8.0版本中引入的一 ...
- InnoSQL/MySQL并行复制的实现与配置
InnoSQL/MySQL并行复制的实现与配置 http://www.innomysql.net/article/6276.html 并行复制之前的解决方案 InnoSQL在5.5.30-v4版本中支 ...
- 各版本 MySQL 并行复制的实现及优缺点
MySQL并行复制已经是老生常谈,笔者从2010年开始就着手处理线上这个问题,刚开始两三年也乐此不疲分享,现在再提这个话题本来是难免“炒冷饭”嫌疑. 最近触发再谈这个话题,是因为有些同学觉得“5.7的 ...
- 【58沈剑架构系列】mysql并行复制优化思路
一.缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重. 为什么mysql主从延时这么大? 回答:从 ...
- MySQL并行复制(MTS)原理(完整版)
目录 MySQL 5.6并行复制架构 MySQL 5.7并行复制原理 Master 组提交(group commit) 支持并行复制的GTID slave LOGICAL_CLOCK(由order c ...
- MySQL 并行复制从库发生自动重启分析
并行复制从库发生自动重启分析 背景 半同步复制从库在晚上凌晨2点半发生自动重启,另一个异步复制从库在第二天凌晨3点也发生了自动重启. 分析 版本mysql 5.7.16 mysql> show ...
- MySQL 并行复制(MTS) 从库更新的记录不存在实际却存在
目录 背景 版本 分析 测试 背景 开了并行复制的半同步从库SQL 线程报1032错误,异步复制从库没有报错,偶尔会出现这种 版本 mysql 5.7.16 redhat 6.8 mysql> ...
随机推荐
- JavaScript经典片段
typeof jQuery != "undefined" || importjQuery(); 判断jQuery对象是否存在,如果不存在就调用importjQuery()方法加载j ...
- greenev —— Python 异步网络服务框架
greenev是一个基于greenlet协程,事件驱动,非阻塞socket模型的Python网络服务框架,它使得可以编写同步的代码,却得到异步执行的优点. 本项目受到gevent, openresty ...
- Java——this关键字
前言 this关键字属于Java中比较复杂的关键字之一,若是学习过C++或者其他的一些面向对象语言也会遇到this这个关键字并且都会看到this的含义就是表示当前对象.什么叫做表示当前对象?this在 ...
- Linux录制、回放和共享终端操作
另一篇终端会话共享的文章:Linux终端会话实时共享(kibitz) 使用script命令录制,使用scriptreplay播放录制的操作.共享终端的操作,则需要使用命名管道来实现. 1.1 录制 [ ...
- Perl一行式:处理空白符号
perl一行式程序系列文章:Perl一行式 假如文件file.log内容如下: root x 0 0 root /root /bin/bash daemon x 1 1 daemon /usr/sbi ...
- 翻译:update语句(已提交到MariaDB官方手册)
本文为mariadb官方手册:UPDATE的译文. 原文:https://mariadb.com/kb/en/update/ 我提交到MariaDB官方手册的译文:https://mariadb.co ...
- cobbler单台服务器实现批量自动化安装不同版本系统-技术流ken
前言 在上一篇博文<cobbler批量安装系统使用详解-技术流ken>中已经详细讲解了cobbler的使用以及安装,本篇博文将会使用单台cobbler实现自动化批量安装不同版本的操作系统. ...
- [转]Laravel 数据库实例教程 —— 使用查询构建器实现对数据库的高级查询
本文转自:https://laravelacademy.org/post/920.html 上一节我们简单介绍了如何使用查询构建器对数据库进行基本的增删改查操作,这一节我们来探讨如何使用查询构建器实现 ...
- 【转载】 Sqlserver查看数据库死锁的SQL语句
在Sqlsever数据库中,有时候操作数据库过程中会进行锁表操作,在锁表操作的过程中,有时候会出现死锁的情况出现,这时候可以使用SQL语句来查询数据库死锁情况,主要通过系统数据库Master数据库来查 ...
- sql 新增 修改 删除 列操作
IF COL_LENGTH('SYS_Department', 'CreatedBy') IS NOT NULL --判断 SYS_Department 中是否存在 CreatedBy 字段 EXEC ...