- 综合排序
- 最热优先
- 最新优先
- 来自专栏爱可生开源社区
故障分析 | MySQL死锁案例分析
作者：杨奇龙网名“北在南方”，资深 DBA，主要负责数据库架构设计和运维平台开发工作，擅长数据库性能调优、故障诊断。 本次分享的一个死锁案例是 涉及通过辅助索引的更新以及通过主键删除导致的死锁。希望能够对想了解死锁的朋友有所帮助。 二 案例分析2.1 业务逻辑select for update 表记录并加上 x 锁，查询数据，做业务逻辑处理，然后删除该记录。还有其他业务逻辑要更新记录，导致死锁。 int not null ,c2 int not null,key idx_c1(c1));insert into dl(c1,c2) values (3,1),(3,2),(3,2),(3,3),( 另外文章的最后我们再次复习一下 MySQL 的加几个基本原则，方便大家后面遇到死锁案例进行分析:原则 1：加锁的基本单位是 next-key lock。原则 2：查找过程中访问到的对象才会加锁。
1.2K30编辑于 2023-01-05 - 来自专栏爱可生开源社区
故障分析 | MySQL死锁案例分析
作者：杨奇龙网名“北在南方”，资深 DBA，主要负责数据库架构设计和运维平台开发工作，擅长数据库性能调优、故障诊断。 本次分享的死锁案例是 更新不存在的记录加上 X GAP lock 和 insert 的意向锁冲突。希望能够对想了解死锁的朋友有所帮助。 二 案例分析2.1 业务逻辑业务逻辑: 业务需要并发不同数据(insert+update)，首先是更新记录，如果发现更新的 affect rows 为0，然后就执行插入，如果插入失败，再执行更新。 row lock(s), undo log entries 1MySQL thread id 3149, OS thread handle 140261085611776, query id 3267 另外文章的最后我们再次复习一下 MySQL 的加几个基本原则，方便大家后面遇到死锁案例进行分析:原则 1：加锁的基本单位是 next-key lock。原则 2：查找过程中访问到的对象才会加锁。
1K41编辑于 2022-12-15 - 来自专栏爱可生开源社区
故障分析 | MySQL 优化案例 - select count(*)
---- 本文关键字：count、SQL、二级索引 相关文章推荐： 故障分析 | MySQL 优化案例 - 字符集转换 技术分享 | MySQL 监控利器之 Pt-Stalk 一、故事背景 项目组联系我说是有一张 调整部分 MySQL 参数，重启 MySQL，保证目前 innodb buffer pool (内存缓冲区) 中为空，不缓存任何数据； 3. key_len: 4 ref: NULL rows: 5117616 filtered: 100.00 Extra: Using index 七、案例总结 使用 MySQL 触发器 + 统计表实时计算表数据量； 2. 使用 MyISAM 替换 InnoDB，因为 MyISAM 自带计数器，坏处就不多说了； 3. 升级到 MySQL 8 中，使用并行查询，加快检索速度。 当然，什么时候 InnoDB 存储引擎可以直接实现计数器的功能就好了！
5.9K30发布于 2020-07-09 - 来自专栏爱可生开源社区
故障分析 | Java 连接 MySQL 8.0 排错案例
作者：胡呈清 爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。 Server 重启了； 2.MySQL MGR 发生切换了； 3.DBA 对 MySQL Server 做了某些变更后。 那前面的解释就显得有点不够了，尤其是第 3 点，开发一定会觉得这是 MySQL 层面的问题或者 DBA 的问题，而不是他们对 MySQL 驱动了解不够。下面就为大家揭晓答案。 之后如果发生以下几种情况： 1.MySQL Server 重启了； 2.MySQL MGR 发生切换了； 3.DBA 对 MySQL Server 做了 flush privileges;。 解决方案 以下方案选择一种即可： 1.应用程序指定 RSA 公钥； 2.应用程序设置 AllowPublicKeyRetrieval=True； 3.MySQL Server 层修改用户的密码加密插件为
1.4K20发布于 2021-03-16 - 来自专栏爱可生开源社区
故障分析 | MySQL 优化案例 - 字符集转换
---- 本文关键字：SQL 优化、字符集 相关文章推荐： 故障分析 | MySQL 派生表优化 故障分析 | 有效解决 MySQL 行锁等待超时问题【建议收藏】 一、背景 开发联系我，说是开发库上有一张视图查询速度很慢 SELECT * FROM view_dataquality_analysis WHERE modelguid = '710adae5-1900-4207-9864-d53ee3a81923' AND configurationguid = '6845d000-cda4-43ea-9fd3-9f9f1f22f95d' limit 20; 我们先去开发库上运行一下这条 SQL，下图中可以看到确实运行很慢 那么基本可以验证我的猜想，当 MySQL 创建视图时，如果发现表连接字段字符集不相同时，会自动添加字符集转换。 另外之前我们有个为什么 b 表没有走索引，是因为缺失了索引吗？的疑问。 其实这个问题有点类似于 int=varchar 隐式转换问题，等号左边为 int 类型，右边为 varchar 类型，那么 MySQL 会自动转换类型为一致，因而无法走索引。
1.7K10发布于 2020-07-02 - 来自专栏爱可生开源社区
故障分析 | MySQL 从机故障重启后主从同步报错案例分析
故障现象 MySQL 从库所在主机故障重启后，sql_thread 线程报错： root@3306 (none)> show slave status\G -- 摘取有用信息如下： Slave_IO_Running 3. :88313207'在主机故障前已经在从库进行了回放，那为何事务会重复回放呢？ 测试验证 搭建一主一从测试环境，通过 sysbench 模拟主库并发插入，从库主机暴力关机后，故障复现： root@mysql.sock][(none)]> select * from performance_schema.replication_applier_status_by_worker ********* CHANNEL_NAME: WORKER_ID: 1 THREAD_ID: NULL SERVICE_STATE: OFF LAST_SEEN_TRANSACTION: 4a0ad3da-b89e
1.2K10编辑于 2022-04-06 - 来自专栏Linux基础 for 凡人
MySQL故障案例 | ERROR 1071 (42000): Specified key was too long
MySQL 建表出现如下错误 （5.7） ERROR 1071 (42000): Specified key was too long； max key length is 3072 bytes查看官网内容得知 innodb_large_prefix is disabled, the index key prefix limit is 767 bytes for tables of any row format. https://dev.mysql.com # 1、在线开启set global innodb_large_prefix = 1;# 2、确认开启show variables like 'innodb_large_prefix';# 3、配置文件配置开启
2.9K00编辑于 2022-06-22 - 来自专栏Kubernetes 与 Devops 干货分享
Docker故障案例分析
案例一 docker启动故障 症状 在执行如下启动命令后docker restart mysql 出现了一下异常报错 docker start mysql Error response from daemon : unknown Error: failed to start containers: mysql 解决方案 # 进入如下目录 cd /run/docker/runtime-runc/moby # # 通过rm -rf命令删除文件夹 # 例如删除症状中的错误id（fd91b9c3f3ca2970c9293042b539759c9fb10f4988548d4cc07aaae85278f719）对应的文件夹 rm -rf fd91b9c3f3ca2970c9293042b539759c9fb10f4988548d4cc07aaae85278f719/ # 删除后重新执行命令，即可启动容器 docker restart mysql
65630编辑于 2022-10-31 - 来自专栏爱可生开源社区
故障分析 | mysql mgr 多主数据不能更新案例浅析
." 1.1.尝试故障恢复操作1 经过初步分析，发现导入的这批数据，在导入节点1可以更新，在其他节点更新失败，怀疑1节点有问题，本着快速恢复故障原则，询问开发得知1节点可以重启，于是对其进行重启，重启后不能加入组复制 2.3.1.环境准备，构造节点3含有本地事务 节点2、节点3故意不关闭参数sql_log_in修改 root 初始密码产生一个本地 gtid ： [root@mysql.sock][(none)]> 2.3.2.故障模拟及恢复 2.3.2.1.当前环境信息：节点3含有本地事务 root@mysql.sock][fxtest]> select * from performance_schema.replication_group_members [root@mysql.sock][fxtest]> 结论：节点1、2都不能修改节点3新增的数据。 [root@mysql.sock][fxtest]> 2.3.2.4.故障修复 2.3.2.5.场景1：节点3本地事务对应 binlog 还存在，如何修复 只需重启节点1、2组复制即可同步过来节点3的本地事务
2.3K20发布于 2021-09-08 - 来自专栏Linux基础 for 凡人
MySQL故障案例 | mysqldump: Couldn’t execute ‘SELECT COLUMN_NAME
disabled by default because histogram generation for large tables can take a long time. https://dev.mysql.com
1.4K00编辑于 2022-06-22 - 来自专栏GreatSQL出品技术文章
故障案例：MySQL唯一索引有重复值，官方却说This is not a bug
问题 原因 故障解决方案 复现步骤 参考文献 一、问题： MySQL5.7.38主从架构，主节点唯一索引上（唯一索引不是主键）有重复值，全部从节点报1062，SQL线程状态异常，根据SQL线程报的binlog 三、故障解决方案： 一、临时解决方案 恢复主从： 在从节点开启会话 set sql_log_bin=0 删除表的唯一索引 重新启动复制线程 缺点是：不能够解决数据重复的问题，切换主从后会面临更多重复数据的问题 ----+------------------+ 10 rows in set (0.00 sec) id=1360 c=3344825394389018 pad=7962994492618902 3. 重新插入重复唯一索引数据： mysql> set unique_checks=0; mysql> use wl mysql> insert into wl.lgf(id,c,pad) values( id=106121) MySQL :: MySQL 8.0 Reference Manual :: 5.1.8 Server System Variables(https://dev.mysql.com
2.1K20编辑于 2023-03-09 - 来自专栏爱可生开源社区
故障分析 | MySQL 启动遭遇 Permission denied 失败案例一则
作者：任坤 现居珠海，先后担任专职 Oracle 和 MySQL DBA，现在主要负责 MySQL、mongoDB 和 Redis 维护工作。 背景 OS：centos 7.9 MySQL：5.7 首次使用某海外云，申请云主机自建 mysql ，service mysqld start 启动报错 Job for mysqld.service # ll ‐ld /data/var drwxr‐xr‐x. 5 mysql mysql 4096 Oct 9 06:14 /data/var # ll /data/var/err.log ‐rw‐r‐ ‐‐‐‐. 1 mysql mysql 33067 Oct 9 06:14 /data/var/err.log service mysqld start 尝试好几次都以失败告终，手工执行 mysqld .... connect(3, {sa_family=AF_UNIX, sun_path="/run/systemd/private"}, 22) = 0 getsockopt(3, SOL_SOCKET
2.5K20编辑于 2022-10-31 - 来自专栏爱可生开源社区
故障分析 | MySQL 异地从库复制延迟案例一则
作者：任坤 现居珠海，先后担任专职 Oracle 和 MySQL DBA，现在主要负责 MySQL、mongoDB 和 Redis 维护工作。 ---- 1、背景 线上某核心 MySQL ，版本为 5.6，本地机房1主2从，同时部署了一个异地从库。 3、小结 借助 perf 和 pstack 工具，能很快定位是压缩表引发的 SQL 线程复制延迟，将大表解压缩后最终解决该问题。 本文关键字：#从库延迟# #perf# #pstack# ---- 关于SQLE 爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，支持多场景审核，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的
51110编辑于 2022-04-06 - 来自专栏爱可生开源社区
故障分析 | 一则 INSERT UPDATE 触发 MySQL Crash 的案例
1故障现象 某业务 MySQL 实例（MySQL 5.7.20 社区版）发生 Crash，现需要对其具体原因进行分析。 ] /mysql/mysql-5.7.20/bin/mysqld(_ZN14Sql_cmd_insert7executeEP3THD+0xce)[0xe9b15e] /mysql/mysql-5.7.20 /bin/mysqld(_Z21mysql_execute_commandP3THDb+0xd82)[0xd13b62] /mysql/mysql-5.7.20/bin/mysqld(_Z11mysql_parseP3THD12Parser_state +0x3a5)[0xd18205] /mysql/mysql-5.7.20/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command +0x11bf)[0xd1942f] 2故障分析 根据堆栈打印的信息可以得知，当时 Crash 的时间点 MySQL 正在执行 INSERT 操作，且操作涉及 BLOB 数据类型的数据，在源码执行到
42710编辑于 2024-04-30 - 来自专栏idba
Redis bigkey 故障案例分析
hvals key 返回 (f1 v1, f2 v2, f3 f3), hget key f1 返回 v1
63820编辑于 2022-12-07 - 来自专栏运维记录点滴
Skype for Business 会议故障案例
Skype for Business 会议故障案例 Lync/Skype for Business客户端创建会议报错，提示连接服务器错误，严重到“现在开会”选项消失。 查看Skype4B前端服务器事件日志，有大量的错误告警，提示连接后端数据库故障及数据库rtcxds日志已满。 ? 已经有了明确的故障错误，重点排查SQL后端数据库，这里要提一下：很多部署Lync/Skype4B的都没有考虑到后端SQL数据库的管理与维护，以致引起一系统的连锁故障。 通过查看后端数据库发现rtcxds数据库日志文件有13G左右，数据库存储磁盘空间也严重不足，以下是收缩数据库的基本做法： 参考：http://www.tuicool.com/articles/NzE3uqN sys.databases where name='rtcxds' 2、备份日志文件 backup log rtcxds to disk='D:\dbbackup\rtcxds-2017-01-06-1.log' 3、
1.7K40发布于 2019-03-05 - 来自专栏运维小白
4.13 磁盘故障小案例
在做实验的时候，写入一行配置到/etc/fstab中去，在做完 lvm实验之后，reboot重启之后，会发现进入不了系统（如下图类似的界面） 本来应该是显示中文，但是在vm终端下，中文不支持，所以看到
70270发布于 2018-02-06 - 来自专栏数据和云
MySQL 传统复制中常见故障处理和结构优化案例分析
虽然MySQL5.7 的主从复制已经很稳定了，但在备库可读写的情况下，总是会出现部分数据不一致的情况，例如常见的1062、1032和1050错误。 环境描述 一 1、mysql 5.7 以上， 2、binlog format 是row格式（5.7默认） 3、传统复制（生产强烈推荐使用gtid） 4、log-bin , log_slave_updates ： set sql_log_bin=0； delete from t2 where id =2; set sql_log_bin=1; start slave; show slave status; 3、 .sock 104 导入数据 mysql -S /tmp/mysql3306.sock -uroot -p123456 < /tmp/1203.sql change 104 到103 change -S /tmp/mysql3306.sock -uroot -p123456 -e "insert into enmo.t2 values($i)"done 关闭103 主机，并检查104 slave
91570发布于 2018-03-08 - 来自专栏我的博客
MySQL主从故障解决
Slave_SQL_Running: No解决 1、在从数据库执行slave stop，停掉同步 2、查看主数据库状态 File: mysql-bin.000003 Position: 1151 3、在从数据库上执行 change master to master_host=’10.200.11.224′,master_user=’slave_test’, master_password=’ 123456′, master_port=3306, master_log_file=’mysql-bin.000003′, master_log_pos=1151; Slave_IO_Running:
96960发布于 2018-04-28 - 来自专栏爱可生开源社区
故障分析 | MySQL 无监听端口故障排查
作者：王向爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。 ---前言最近解决了一个比较基础的问题故障，由于排查过程挺有意思，于是就以此为素材写出了本篇文章。故障现场防火墙什么的均正常但是无法被远程访问到。简单的使用客户端登录了一下。 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)根据以往经验大脑中浮现了几个常见的排查此类故障手法1.排查进程存在 --pid-file=/mysqldata/mysql/data/3308/mysqld.pid --user=mysql --socket=/mysqldata/mysql/data/3308/mysqld.sock 解决方案因为配置 skip-grants-tables 引起无法远程连接 mysql 服务端的故障，解决方法也是非常的简单注释重启。
1.2K20编辑于 2022-09-08
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号