记录一次开发环境问题 MySQL trx_mysql_thread_id=0事务导致表死锁(未解决)

###现象
1.服务出现jdbc链接池没有可用链接(获取连接等待超时)
2.show full processlist 发现存在该服务大量select 某表的query全部watting flush tables 一条请求flush table 一条请求open table
3.kill 掉flush table 请求后,在processlist中不再找到该请求,但是后续请求继续阻塞,kill 掉open table请求后,open table无限期处于killed状态,依旧获取不到锁
4.使用select 查询该表,无限期死锁
5.查询information_schema.INNODB_TRX;发现有一条三天前的事务,事务trx_mysql_thread_id=0 隔离级别read_uncommit 状态running 事务开启时间为9:03
6.解析binlog 该事务启动后,无任何9:03左右该事务的记录
7.xa recover; 无任何事务信息
8.查询INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 无任何记录
9.查询INFORMATION_SCHEMA.INNODB_LOCKS; 无任何记录
10.重启mysql,无法启动。
11.查看mysql启动日志, 处理事务文件ib_logfile0 ib_logfile1 ibdata1异常
12.查看网上方法,删除了事务文件及事务日志ib_logfile0 ib_logfile1
13.启动mysql 成功。

待后续深入学习mysql 回顾该问题。

解决MySQL主从延时的方法之一是通过临时修改sync_binlog参数和innodb_flush_log_at_trx_commit参数来实现。具体介绍如下: 1. sync_binlog参数: - 该参数用于控制二进制日志的同步方式。默认情况下,sync_binlog参数的值为1,示每次事务提交时都会将二进制日志同步到磁盘上。 - 临时将sync_binlog参数设置为5000,意味着每隔5000个事务提交才会将二进制日志同步到磁盘上,从而减少了磁盘IO的频率,提高了性能。 - 但是,这样做也增加了数据丢失的风险,因为如果在两次同步之间发生故障,可能会丢失最近的5000个事务的数据。 2. innodb_flush_log_at_trx_commit参数: - 该参数用于控制InnoDB存储引擎的日志刷新策略。默认情况下,innodb_flush_log_at_trx_commit参数的值为1,示每次事务提交时都会将日志刷新到磁盘上。 - 临时将innodb_flush_log_at_trx_commit参数设置为0,意味着每次事务提交时不会立即将日志刷新到磁盘上,而是由InnoDB引擎自行决定刷新的时机。 - 这样做可以提高性能,减少磁盘IO的频率,但也增加了数据丢失的风险,因为在发生故障时可能会丢失最近提交的事务的数据。 利弊如下: - 利:通过临时修改sync_binlog参数和innodb_flush_log_at_trx_commit参数,可以减少磁盘IO的频率,提高数据库的性能。 - 弊:临时修改这两个参数会增加数据丢失的风险,因为在发生故障时可能会丢失最近提交的事务的数据。此外,如果忘记还原这些参数的值,可能会导致数据不一致或数据丢失的问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值