16 posts tagged with "mysql"

Invalid JSON text in argument 2 in mysql8

June 7, 2023 · One min read

背景

有个update_rules字段是json类型

{"type": "once", "values": []}

想用JSON_CONTAINS提取中间的once内容,发现下面这个sql一直报错:

SELECT  *  FROM  `usergroup`  WHERE JSON_CONTAINS(update_rules , 'once' , '$.type' )

报错一直是Invalid JSON text in argument 2 , 看了很久也没有看出第二个参数哪里错了

mysql官网例子 , 我看官网也是这样

解决方式

搜索了一下stackoverflow,原来字符串还要在里面加双引号

也就是'once' 改成'"once"'

完整的sql变成如下:

SELECT  *  FROM  `usergroup`  WHERE JSON_CONTAINS(update_rules , '"daily"' , '$.type' )

背景

insert ignore sql死锁了

排查

日志

排查了死锁日志: 我们定位到是有个表,简单来说,是有两个字段:

id : 主键
email_address: 唯一索引

一共有两个线程在写入,每次的操作就是批量用insert ignore写入,初步看都是很简单的sql, 后面google一下发现是和间隙锁有关: 相关blog

2023-05-03 05:06:45 0x4002719ffef0
*** (1) TRANSACTION:
TRANSACTION 218982374, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 7 lock struct(s), heap size 1136, 4 row lock(s)
MySQL thread id 481964, OS thread handle 70370189385456, query id 1320790141 10.4.3.228 app_cdp_0 update
insert ignore into cdp_user_email
        (email_address,
        clean_tag,
        is_upload_emarsys,
        created_at,
        upload_at
        )
        value


*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 189 page no 328322 n bits 272 index PRIMARY of table `customer_data_platform`.`cdp_user_email` trx id 218982374 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;


*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 189 page no 328322 n bits 272 index PRIMARY of table `customer_data_platform`.`cdp_user_email` trx id 218982374 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;


*** (2) TRANSACTION:
TRANSACTION 218982373, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 11 lock struct(s), heap size 1136, 6 row lock(s)
MySQL thread id 481963, OS thread handle 70370189655792, query id 1320790139 10.4.3.228 app_cdp_0 update
insert ignore into cdp_user_email
        (email_address,
        clean_tag,
        is_upload_emarsys,
        created_at,
        upload_at
        )
        value
        

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 189 page no 328322 n bits 272 index PRIMARY of table `customer_data_platform`.`cdp_user_email` trx id 218982373 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;


*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 189 page no 328322 n bits 272 index PRIMARY of table `customer_data_platform`.`cdp_user_email` trx id 218982373 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** WE ROLL BACK TRANSACTION (1)

修改方式

将批量insert 改成每次只写入一条

mysql 5.7 in 的优化引起的bug

July 29, 2021 · 3 min read

起因

有个1700w的表需要初始化 , 然后我们需要分批取id范围是[1 , 1000) , [1000 , 2000)的值

问题

很简单的sql

update  test set    a.value=1 where id in ( 1 , 2 , 7 , 9.... 1000);
update  test set    a.value=1 where id in ( 1001 , 1002 , 1005 , ... 2000);

这里的id大概有100个左右 ,id是单调递增,基本连续

测试环境很正常,非常快 , 通过这个sql , 我们可以一秒update 1w以上的行

但是生产环境这个update特别特别慢,update 1000 行大概需要 50s以上

排查

定位经过很多尝试,
定位到是update这个sql特别慢,而且是但是测试环境非常快,生产环境非常慢

尝试explain

explain 
update  test as a set    a.value=1 where id in ( 1 , 2 , 7 , 9....);

生产环境下是这样:

Using where; Using temporary

但是测试环境是:

Using where

开始搜索,找到了类似的原因: https://bugs.mysql.com/bug.php?id=80424 对比了一下版本: 生产环境:5.7.9-log 测试环境:5.7.22-log

确定binlog的记录形式:

SELECT @@binlog_row_image

结果是

FULL

这个bug被5.7.15以上修复,所以测试环境没有问题,生产环境有问题

解决

因为生产版本的mysql几乎没有升级的可能,这个批量的刷数据如果10条/s估计要刷一个星期,所以我们尝试了很多写法避免这个优化,最后使用了这个写法避免生产版本的mysql的bug 不使用in 而是使用join 防止这个优化器的bug

DESC
UPDATE `test` a JOIN (
SELECT id FROM test t   WHERE  `id` IN (516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,533,532)
) t ON a.id = t.id
SET a.isvisible = -1;

优化后不用temp了

"id"	"select_type"	"table"	"partitions"	"type"	   "possible_keys"	"key"	"key_len"	"ref"	"rows"	"filtered"	"Extra"
"1"	    "UPDATE"	     "a"	\N	            "range"	    "PRIMARY"	    "PRIMARY"	"4"	     \N	    "104"	"100.00"	"Using where"
"1"	    "SIMPLE"	     "b"	\N	            "eq_ref"	"PRIMARY"	   "PRIMARY"	"4"	   "a.id"	"1"	    "100.00"	"Using index"

事后扒代码

通过https://bugs.mysql.com/bug.php?id=80424 提供的patch大概定位到原因

为什么会使用temp表?

第六个参数是判断是否需要使用temp的 ,也就是 !using_filesort && (used_key_is_modified || order)

    Modification_plan plan(thd, MT_UPDATE, &qep_tab,
                           used_index, limit,
                           (!using_filesort && (used_key_is_modified || order)),
                           using_filesort, used_key_is_modified, rows);

查看Modification_plan这个类的定义:

  Modification_plan(THD *thd_arg,
                    enum_mod_type mt, QEP_TAB *qep_tab,
                    uint key_arg, ha_rows limit_arg, bool need_tmp_table_arg,
                    bool need_sort_arg, bool used_key_is_modified_arg,
                    ha_rows rows);

在这个问题中是 used_key_is_modified = true, 所以会产生temp表

mysql 报文:

mysql报文分为两部分:header和payload

有四个字节,其中前三个字节是标识这个包的长度描述payload的长度,也就是payload最长的长度为2^24-1字节,最后一个字节则是类似于tcp的序列号,每次从0开始递增,描述的是第几个包

payload

payload则是具体负载

mysql握手

tcp三次握手之后,整个传输层的连接已经建立了,那么怎么登陆呢? 握手文档加密的方式举个例子:加密套件是mysql_native_password,那么第一个包会是由 server发出,附带20字节的随机码, 然后在客户端的用户提交的密码做多次sha1哈希然后回传给mysql

binlog获取分为两步:

1: COM_REGISTER_SLAVE 把slave注册到master里面 2: COM_BINLOG_DUMP 这个包主要是告诉master锁需要的binlog的名字和位点,然后就会返回一堆binlog事件给客户端

mysql 发送binlog流程

int Binlog_sender::get_binlog_end_pos(File_reader *reader, my_off_t *end_pos) {
  DBUG_TRACE;
  my_off_t read_pos = reader->position();

  do {
    /*
      MYSQL_BIN_LOG::binlog_end_pos is atomic. We should only acquire the
      LOCK_binlog_end_pos if we reached the end of the hot log and are going
      to wait for updates on the binary log (Binlog_sender::wait_new_event()).
    */
    *end_pos = mysql_bin_log.get_binlog_end_pos();

    /* If this is a cold binlog file, we are done getting the end pos */
    if (unlikely(!mysql_bin_log.is_active(m_linfo.log_file_name))) {
      *end_pos = 0;
      return 0;
    }

    DBUG_PRINT("info", ("Reading file %s, seek pos %llu, end_pos is %llu",
                        m_linfo.log_file_name, read_pos, *end_pos));
    DBUG_PRINT("info", ("Active file is %s", mysql_bin_log.get_log_fname()));

    if (read_pos < *end_pos) return 0;

    /* Some data may be in net buffer, it should be flushed before waiting */
    if (!m_wait_new_events || flush_net()) return 1;

    if (unlikely(wait_new_events(read_pos))) return 1;
  } while (unlikely(!m_thd->killed));

  return 1;
}

mysql主从

April 14, 2021 · One min read

  DBUG_PRINT("info", ("Creating new slave thread"));
  if (mysql_thread_create(thread_key, &th, &connection_attrib, h_func,
                          (void *)mi)) {
    LogErr(ERROR_LEVEL, ER_RPL_CANT_CREATE_SLAVE_THREAD,
           mi->get_for_channel_str());
    my_error(ER_SLAVE_THREAD, MYF(0));
    goto err;
  }

slave 线程

/**
  Slave SQL thread entry point.

  @param arg Pointer to Relay_log_info object that holds information
  for the SQL thread.

  @return Always 0.
*/
extern "C" void *handle_slave_sql(void *arg) {
  THD *thd; /* needs to be first for thread_stack */
  bool thd_added = false;
  bool main_loop_error = false;
  char llbuff[22], llbuff1[22];

比较坑的点:

1 每次同步的内容会每秒持久化到file或者zk ,binlog一般只保留的几天,如果你持久化到文件/zk的配置的binlog文件在mysql已经不存在了会报错, 报错信息大概如下

java.io.IOException: Received error packet: errno = 1236, sqlstate = HY000 errmsg = Could not find first log file name in binary log index file

这个时候只能调整配置或者删除mate.dat 文件,然后重启canal , 这个时候他会使用mysql的语句show status去取最新位点

2 重启canal有个非常非常坑的点在于会读information_schema 这个库的内容去读表名和表id等信息 ,而这个往往会很久,不知道是不是测试环境原因,读了挺久的

mate刷新的逻辑

根据配置每秒刷新到mate信息也就是文件或者zk上,所以重启会有重复消费

找到位点

加载顺序: 1 从mate中获取位点: getLatestIndexBy 也就是从 memeory/zk或者file的mate信息中读取位点 2 根据配置读取:

    protected EntryPosition findStartPositionInternal(ErosaConnection connection) {
        MysqlConnection mysqlConnection = (MysqlConnection) connection;
        LogPosition logPosition = logPositionManager.getLatestIndexBy(destination);
        if (logPosition == null) {// 找不到历史成功记录
            EntryPosition entryPosition = null;
            if (masterInfo != null && mysqlConnection.getConnector().getAddress().equals(masterInfo.getAddress())) {
                entryPosition = masterPosition;
            } else if (standbyInfo != null
                       && mysqlConnection.getConnector().getAddress().equals(standbyInfo.getAddress())) {
                entryPosition = standbyPosition;
            }

            if (entryPosition == null) {
                entryPosition = findEndPositionWithMasterIdAndTimestamp(mysqlConnection); // 默认从当前最后一个位置进行消费
            }

            // 判断一下是否需要按时间订阅
            if (StringUtils.isEmpty(entryPosition.getJournalName())) {
                // 如果没有指定binlogName，尝试按照timestamp进行查找
                if (entryPosition.getTimestamp() != null && entryPosition.getTimestamp() > 0L) {
                    logger.warn("prepare to find start position {}:{}:{}",
                        new Object[] { "", "", entryPosition.getTimestamp() });
                    return findByStartTimeStamp(mysqlConnection, entryPosition.getTimestamp());
                } else {
                    logger.warn("prepare to find start position just show master status");
                    return findEndPositionWithMasterIdAndTimestamp(mysqlConnection); // 默认从当前最后一个位置进行消费
                }
            } else {
                if (entryPosition.getPosition() != null && entryPosition.getPosition() > 0L) {
                    // 如果指定binlogName + offest，直接返回
                    entryPosition = findPositionWithMasterIdAndTimestamp(mysqlConnection, entryPosition);
                    logger.warn("prepare to find start position {}:{}:{}",
                        new Object[] { entryPosition.getJournalName(), entryPosition.getPosition(),
                                entryPosition.getTimestamp() });
                    return entryPosition;
                } else {
                    EntryPosition specificLogFilePosition = null;
                    if (entryPosition.getTimestamp() != null && entryPosition.getTimestamp() > 0L) {
                        // 如果指定binlogName +
                        // timestamp，但没有指定对应的offest，尝试根据时间找一下offest
                        EntryPosition endPosition = findEndPosition(mysqlConnection);
                        if (endPosition != null) {
                            logger.warn("prepare to find start position {}:{}:{}",
                                new Object[] { entryPosition.getJournalName(), "", entryPosition.getTimestamp() });
                            specificLogFilePosition = findAsPerTimestampInSpecificLogFile(mysqlConnection,
                                entryPosition.getTimestamp(),
                                endPosition,
                                entryPosition.getJournalName(),
                                true);
                        }
                    }

                    if (specificLogFilePosition == null) {
                        // position不存在，从文件头开始
                        entryPosition.setPosition(BINLOG_START_OFFEST);
                        return entryPosition;
                    } else {
                        return specificLogFilePosition;
                    }
                }
            }
        } else {
            if (logPosition.getIdentity().getSourceAddress().equals(mysqlConnection.getConnector().getAddress())) {
                if (dumpErrorCountThreshold >= 0 && dumpErrorCount > dumpErrorCountThreshold) {
                    // binlog定位位点失败,可能有两个原因:
                    // 1. binlog位点被删除
                    // 2.vip模式的mysql,发生了主备切换,判断一下serverId是否变化,针对这种模式可以发起一次基于时间戳查找合适的binlog位点
                    boolean case2 = (standbyInfo == null || standbyInfo.getAddress() == null)
                                    && logPosition.getPostion().getServerId() != null
                                    && !logPosition.getPostion().getServerId().equals(findServerId(mysqlConnection));
                    if (case2) {
                        EntryPosition findPosition = fallbackFindByStartTimestamp(logPosition, mysqlConnection);
                        dumpErrorCount = 0;
                        return findPosition;
                    }
                    // 处理 binlog 位点被删除的情况，提供自动重置到当前位点的功能
                    // 应用场景: 测试环境不稳定，位点经常被删。强烈不建议在正式环境中开启此控制参数，因为binlog 丢失调到最新位点也即意味着数据丢失
                    if (isAutoResetLatestPosMode()) {
                        dumpErrorCount = 0;
                        return findEndPosition(mysqlConnection);
                    }
                    Long timestamp = logPosition.getPostion().getTimestamp();
                    if (isRdsOssMode() && (timestamp != null && timestamp > 0)) {
                        // 如果binlog位点不存在，并且属于timestamp不为空,可以返回null走到oss binlog处理
                        return null;
                    }
                } else if (StringUtils.isBlank(logPosition.getPostion().getJournalName())
                        && logPosition.getPostion().getPosition() <= 0
                        && logPosition.getPostion().getTimestamp() > 0) {
                    return fallbackFindByStartTimestamp(logPosition,mysqlConnection);
                }
                // 其余情况
                logger.warn("prepare to find start position just last position\n {}",
                    JsonUtils.marshalToString(logPosition));
                return logPosition.getPostion();
            } else {
                // 针对切换的情况，考虑回退时间
                long newStartTimestamp = logPosition.getPostion().getTimestamp() - fallbackIntervalInSeconds * 1000;
                logger.warn("prepare to find start position by switch {}:{}:{}", new Object[] { "", "",
                        logPosition.getPostion().getTimestamp() });
                return findByStartTimeStamp(mysqlConnection, newStartTimestamp);
            }
        }

事件类型

事件有很多类型,我现在只对update和insert 感兴趣

public enum EventType
      implements com.google.protobuf.ProtocolMessageEnum {
    /**
     * <code>INSERT = 1;</code>
     */
    INSERT(0, 1),
    /**
     * <code>UPDATE = 2;</code>
     */
    UPDATE(1, 2),
    /**
     * <code>DELETE = 3;</code>
     */
    DELETE(2, 3),
    /**
     * <code>CREATE = 4;</code>
     */
    CREATE(3, 4),
    /**
     * <code>ALTER = 5;</code>
     */
    ALTER(4, 5),
    /**
     * <code>ERASE = 6;</code>
     */
    ERASE(5, 6),
    /**
     * <code>QUERY = 7;</code>
     */
    QUERY(6, 7),
    /**
     * <code>TRUNCATE = 8;</code>
     */
    TRUNCATE(7, 8),
    /**
     * <code>RENAME = 9;</code>
     */
    RENAME(8, 9),
    /**
     * <code>CINDEX = 10;</code>
     *
     * <pre>
     **CREATE INDEX*
     * </pre>
     */
    CINDEX(9, 10),
    /**
     * <code>DINDEX = 11;</code>
     */
    DINDEX(10, 11),
    /**
     * <code>GTID = 12;</code>
     */
    GTID(11, 12),
    /**
     * <code>XACOMMIT = 13;</code>
     *
     * <pre>
     ** XA *
     * </pre>
     */
    XACOMMIT(12, 13),
    /**
     * <code>XAROLLBACK = 14;</code>
     */
    XAROLLBACK(13, 14),
    /**
     * <code>MHEARTBEAT = 15;</code>
     *
     * <pre>
     ** MASTER HEARTBEAT *
     * </pre>
     */
    MHEARTBEAT(14, 15),
    ;

相关阅读

http://www.tianshouzhi.com/api/tutorials/canal

如何读取mysql的binlog?

可以使用mysql默认的mysqlbinlog

重要的是需要加v 命令

mysqlbinlog   -v  mysql-bin.000006

你会看到具体的sql了,我这里的sql是

#210311 14:51:10 server id 1  end_log_pos 1606 CRC32 0x783f56ab 	Query	thread_id=64	exec_time=0	error_code=0
SET TIMESTAMP=1615445470/*!*/;
BEGIN
/*!*/;
# at 1606
#210311 14:51:10 server id 1  end_log_pos 1672 CRC32 0x52632df5 	Table_map: `user_db`.`tb_user` mapped to number 119
# at 1672
#210311 14:51:10 server id 1  end_log_pos 1783 CRC32 0xf565f574 	Update_rows: table id 119 flags: STMT_END_F

BINLOG '
3r1JYBMBAAAAQgAAAIgGAAAAAHcAAAAAAAEAB3VzZXJfZGIAB3RiX3VzZXIABgMPDw8BDwgUAEAA
FAAyADj1LWNS
3r1JYB8BAAAAbwAAAPcGAAAAAHcAAAAAAAEAAgAG///AYAAAAAI5NgYxMjM0NTYFOTk5OTcSD3po
YW5nc2FuQGJ1Zy5jbsBgAAAAATUGMTIzNDU2BTk5OTk3Eg96aGFuZ3NhbkBidWcuY2509WX1
'/*!*/;
### UPDATE `user_db`.`tb_user`
### WHERE
###   @1=96
###   @2='96'
###   @3='123456'
###   @4='99997'
###   @5=18
###   @6='zhangsan@bug.cn'
### SET
###   @1=96
###   @2='5'
###   @3='123456'
###   @4='99997'
###   @5=18
###   @6='zhangsan@bug.cn'
# at 1783
#210311 14:51:10 server id 1  end_log_pos 1814 CRC32 0xa90279ec 	Xid = 1794
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*/;

协议流程

COM_BINLOG_DUMP -> com_binlog_dump

第一步其实和php差不多,先是编译原理的前端几步lex和parse 第二步就是逻辑优化和物理优化, 其实可以想成是常用的编程语言的常量折叠或者数据流图的分析,就是编译时的优化第三步也就是语义动作了,也就是真正的执行过程也可以想做是运行时: 但是条件对于读来说是不可见的,条件是作用于索引上 , 然后返回所有行 , 再根据列筛选出来,然后再join和排序,对于这个sql来说,他唯一作用就是通过索引读出内容,内存和硬盘对于他来说是不存在的

首先是读表,这个表是从ibd文件来的.所以终究是需要调用系统调用读文件,那么linux用系统调用是pread

索引在哪保存? 保存在表空间里面内容保存到哪里? 保存到表空间里面关联是在哪里发生? 发生在从索引从表空间读出来关联是整整一行关联吗? 是的. 二级索引怎么读的? 通过二级索引读一级索引,一级索引读内容.

所以实际上是有一个语义上的层是: sql -> 语义动作作用于索引 -> 索引访问表空间(有点像交换空间或者物理内存和虚拟内存的关系一样一样, 需要的时候才从硬盘硬盘加载)

下面是相关代码

(gdb) bt
#0  srv_start (create_new_db=create_new_db@entry=false) at /home/ubuntu/mysql-8.0.23/storage/innobase/srv/srv0start.cc:1857
#1  0x00005555577275b6 in innobase_init_files (tablespaces=0x7fffea1f1380, dict_init_mode=DICT_INIT_CHECK_FILES) at /home/ubuntu/mysql-8.0.23/storage/innobase/handler/ha_innodb.cc:5042
#2  innobase_ddse_dict_init (dict_init_mode=DICT_INIT_CHECK_FILES, version=<optimized out>, tables=0x7fffea1f1360, tablespaces=0x7fffea1f1380)
    at /home/ubuntu/mysql-8.0.23/storage/innobase/handler/ha_innodb.cc:12323
#3  0x00005555573d2aef in dd::bootstrap::DDSE_dict_init (thd=thd@entry=0x55555b899410, dict_init_mode=dict_init_mode@entry=DICT_INIT_CHECK_FILES, version=80023)
    at /home/ubuntu/mysql-8.0.23/sql/dd/impl/bootstrap/bootstrapper.cc:737
#4  0x00005555575f92e4 in dd::upgrade_57::do_pre_checks_and_initialize_dd (thd=0x55555b899410) at /home/ubuntu/mysql-8.0.23/sql/dd/upgrade_57/upgrade.cc:911
#5  0x0000555556697ec5 in bootstrap::handle_bootstrap (arg=arg@entry=0x7fffffffda10) at /home/ubuntu/mysql-8.0.23/sql/bootstrap.cc:323
#6  0x0000555557b934a1 in pfs_spawn_thread (arg=0x55555b834c80) at /home/ubuntu/mysql-8.0.23/storage/perfschema/pfs.cc:2900
#7  0x00007ffff7bbb6db in start_thread (arg=0x7fffea1f2700) at pthread_create.c:463
#8  0x00007ffff61b571f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(gdb) info threads 
  Id   Target Id         Frame 
  1    Thread 0x7ffff7fe7880 (LWP 17988) "mysqld" 0x00007ffff7bbcd2d in __GI___pthread_timedjoin_ex (threadid=140737121298176, thread_return=thread_return@entry=0x0, abstime=abstime@entry=0x0, 
    block=block@entry=true) at pthread_join_common.c:89
* 2    Thread 0x7fffea1f2700 (LWP 18000) "mysqld" __libc_pread64 (fd=4, buf=0x7fffe81d0000, count=65536, offset=0) at ../sysdeps/unix/sysv/linux/pread64.c:29
  4    Thread 0x7fffe8f49700 (LWP 18269) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42eda10)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  5    Thread 0x7fffe3b32700 (LWP 18270) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edab0)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  6    Thread 0x7fffe3331700 (LWP 18271) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edb50)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  7    Thread 0x7fffe2b30700 (LWP 18272) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edbf0)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  8    Thread 0x7fffe232f700 (LWP 18273) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edc90)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  9    Thread 0x7fffe1b2e700 (LWP 18274) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edd30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  10   Thread 0x7fffe132d700 (LWP 18275) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42eddd0)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  11   Thread 0x7fffe0b2c700 (LWP 18276) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42ede70)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  12   Thread 0x7fffd3d5f700 (LWP 18277) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edf10)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  13   Thread 0x7fffd355e700 (LWP 18278) "mysqld" 0x00007ffff7bc1ad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffe42edfb0)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  14   Thread 0x7fffd2d5d700 (LWP 18279) "mysqld" 0x00007ffff6ace280 in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

背景​

解决方式​

相关阅读​

背景​

排查​

日志​

修改方式​

起因​

问题​

排查​

解决​

事后扒代码​

mysql 报文:​

header​

payload​

mysql握手​

binlog获取分为两步:​

mysql 发送binlog流程​

比较坑的点:​

mate刷新的逻辑​

找到位点​

事件类型​

相关阅读​

如何读取mysql的binlog?​

协议流程​

相关阅读​

为什么想看select的代码​

一个简单的select语句​

下面是相关代码​

相关阅读​

背景

解决方式

相关阅读

背景

排查

日志

修改方式

起因

问题

排查

解决

事后扒代码

mysql 报文:

header

payload

mysql握手

binlog获取分为两步:

mysql 发送binlog流程

比较坑的点:

mate刷新的逻辑

找到位点

事件类型

相关阅读

如何读取mysql的binlog?

协议流程

相关阅读

为什么想看select的代码

一个简单的select语句

下面是相关代码

相关阅读