问题背景:
用户的rds数据库,最近出现了这样一个问题:没有使用读写分离,提交一个update语句修改状态值,修改之后,当时查不到修改后的值,查到的还是修改前的值,过了2小时之后才可以查到,审计日志看sql语句是更新成功的。
以下是用户提供的截图信息
问题分析:
通过截图可以看到将invest_status状态值修改为3,但是navica 查到的还是修改前的值2。
解析binlog看,日志里确实有执行成功过update,看用户的截图。binlog信息里看### @13=3 / INT meta=0 nullable=1 is_null=0 / 该字段确实修改了。
现场排查:
下午用户侧复现问题,联系我们继续分析,还是做了update但是查不到结果。SQL语句是这样的:
UPDATE project_periods SET return_time=1563166809672 , return_status = 2 , update_time = 1563166809672 WHERE pro_id = 104 and new_period = 5
查询时候确实没有被更新
审计日志里看当时确实update过这个sql
分析:SQL审计里我们看到的SQL语句,是执行过,但是未必提交,因此还需进一步分析
select * from information_shema.innodb_trx ,发现有与用户反馈时间一致的一个线程处于running状态,并未被提交
show processlist可以看到该SQL线程15833244
说明正如分析所说,事务还未提交,而RDS的默认隔离级别是RC,如果不在一个事务里查询,事务提交之前其他会话看不到,RC隔离级别是提交读,也就是提交后,其他会话才能查到。过了2小时左右事务被提交,审计里看到了该SQL线程15833244 commit
用户侧确认是框架修改后,事务自动提交部分有变导致的,问题解决。
附上事务隔离级别说明,RDS默认隔离级别RC: