升级到Aurora MySQL 5.7后的表锁定问题

0

【以下的问题经过翻译处理】 由于MySQL 5.6即将停止支持,我们已将其中一个5.6的Aurora无服务器MySQL集群升级到5.7。自我们进行升级以来,我们面临了许多问题,尤其是与表锁定相关的问题,在过去的5.6里,我们从未遇到过这些问题。我们尝试更改隔离级别、禁用缓存以及许多其他选项,但过去几天都没有提供任何有用的结果。它仍然会在具有极少量数据的表上卡在UPDATE查询中具有WHERE子句中的PK。间隙锁、死锁或锁未在进程清理时处理,我们目前无法确定。有人遇到类似的问题吗?请建议。

---TRANSACTION 960499483, ACTIVE 12 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) MySQL thread id 43, OS thread handle 47444799534848, query id 36684 10.1.28.175 admin updating UPDATE bulk_import_hist_tracking set records_count =IFNULL(nullif(1, ''), records_count), practiceid = 123, submission_status = 'test',s3_url = NULLIF('test', ''), updatedat=now() where target_resource_id = 1 ------- TRX HAS BEEN WAITING 12 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 15857 page no 4 n bits 0 index PRIMARY of table embry_care_db.bulk_import_hist_tracking trx id 960499483 lock_mode X locks rec but not gap waiting Record lock, heap no 111 PHYSICAL RECORD: n_fields 15; compact format; info bits 0 0: len=4; bufptr=0x2b27454f67bb; hex= 80000001; asc ;; 1: len=6; bufptr=0x2b27454f67bf; hex= 000039400ccf; asc 9@ ;; 2: len=7; bufptr=0x2b27454f67c5; hex= 300000642917c5; asc 0 d) ;; 3: len=4; bufptr=0x2b27454f67cc; hex= 8000007b; asc {;; 4: len=7; bufptr=0x2b27454f67d0; hex= 44425f74657374; asc DB_test;; 5: SQL NULL; 6: len=3; bufptr=0x2b27454f67d7; hex= 8fcd8e; asc ;; 7: len=4; bufptr=0x2b27454f67da; hex= 80000001; asc ;; 8: len=2; bufptr=0x2b27454f67de; hex= 4442; asc DB;; 9: len=4; bufptr=0x2b27454f67e0; hex= 74657374; asc test;; 10: len=1; bufptr=0x2b27454f67e4; hex= 80; asc ;; 11: len=4; bufptr=0x2b27454f67e5; hex= 6399cc81; asc c ;; 12: len=4; bufptr=0x2b27454f67e9; hex= 63dce65b; asc c [;; 13: len=4; bufptr=0x2b27454f67ed; hex= 74657374; asc test;; 14: SQL NULL;

1 回答
0

【以下的回答经过翻译处理】 这似乎是由于一个过程有一个错误,没有正确关闭连接造成的。修复后似乎解决了这个问题。感谢大家。

profile picture
专家
已回答 8 个月前

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则