ITPub博客

问题描述Xtrabackup 2.4.18 备份报错：Unable to obtain lock. Please try again later.环境信息Xtrabackup 2.4.18MySQL 5.7.21问题总结备份语句指定--ftwrl-wait-timeout=60，备份期间有select语句执行耗时超过60秒，FTWRL等待锁时间大于ftwrl-wait-timeout设置的时间，则

环境信息 MySQL 5.7.21 文件系统 ext3问题描述 单表idb文件达到2T（ext3文件系统单文件最大限制），当表insert时会报错 the table is full，开发紧急delete掉6万行数据后，ibd文件大小未减小，insert新数据继续报错 the table is full 。（ps:临时应急：在未改变文件系统ext3的情况下，rename 旧表，建同名新表，确

问题描述MySQL 5.7.21 业务表无法访问，select 业务表直接导致mysql crash，errorlog 里记录 [ERROR] InnoDB: Page [page id: space=49, page number=3] log sequence number 89266322606 is in the future! Current system log sequence nu

问题描述 相同SQL在不同MySQL版本中查询相同数据的查询结果不一致，高版本3.0.32查询结果符合预期（查询有结果），低版本8.0.25查询结果不符合预期（查询无结果）。 分析：业务SQL包含用户自定义变量赋值，SQL在不同版本的执行计划不一样，推测可能受optimizer_switch的影响。BUG定位参考：https://bugs.mysql.com/bug.php?i

问题背景几天前，该环境ibdata1的size被置为0,无法启动，使用传输表空间等特殊恢复手段，恢复数据到新实例。再次收到通知，MySQL无法访问了，来看看。错误日志如下起初，以为是一条关联select触发了mysql bug导致实例崩溃。相关表的表结构，如下所示。既然之前该实例是经过特殊恢复重建的，能不能把数据导出再导入呢？发现导出时 interface_mng 表访问存在异常。select c

问题现象描述环境概述：MySQL 8.0.25；问题简述：2024/1/31 凌晨3点 应用批量报 The table  ’/data_tmp/mysql_xx….’ is full 。表的大小9GB,报错SQL语句如下:SQL执行计划2.问题处理过程业务跑批失败的SQL语句，应用手工重新执行。3. 问题分析3.1 数据库错误日志：数据库mysql.err日志发现有相应的报错信息：错误信

问题描述MySQL 8.0.25 在 2023/12/22  10:17:36 左右 出现线程堵塞，正常情况下原本执行很快的sql执行效率陡降（比如：原本执行0.001秒的sql执行7秒仍未结束），导致十几笔交易超时。问题分析根据AWR处于非Sleep状态的用户线程，Time由高到低排序，执行耗时第一为Command处于Query执行耗时达30秒，是对 performance_schem