The table lock is not released until 60 seconds after a failed table cut
维护者通常 10 天内回复
还没有人认领这个 Issue。
评估
调研方向
首先跟踪 AllEventsUpToLockProcessed 超时后的 cut-over 处理，重点关注 issue 中展示的 magic-table 删除以及随后进行的表解锁。使用 MySQL 8.0.24 和 gh-ost 1.1.5 重现；完成标准是：当 magic-table 删除等待其 metadata lock 时，失败的 cut-over 不会延迟释放原始表锁。
由索引模型根据 Issue 内容生成。
描述
After waiting for AllEventsUpToLockProcessed to timeout, the database instance experienced a large amount of metadata waiting for 60 seconds。
Because the sentence "unlock tables" cannot be executed until 60 seconds
mysql version：8.0.24 ghost version: 1.1.5
the log：
2023-03-17 18:13:55 INFO Grabbing voluntary lock: gh-ost.34100417.lock
2023-03-17 18:13:55 INFO Setting LOCK timeout as 6 seconds
2023-03-17 18:13:55 INFO Looking for magic cut-over table
2023-03-17 18:13:55 INFO Creating magic cut-over table db1._test_20230317181349_del
2023-03-17 18:13:55 INFO Magic cut-over table created
2023-03-17 18:13:55 INFO Locking db1.test, db1._test_20230317181349_del
2023-03-17 18:13:55 INFO Tables locked
2023-03-17 18:13:55 INFO Session locking original & magic tables is 34100417
2023-03-17 18:13:55 INFO Writing changelog state: AllEventsUpToLockProcessed:1679048035119299226
2023-03-17 18:13:55 INFO Waiting for events up to lock
2023-03-17 18:13:58 ERROR Timeout while waiting for events up to lock
2023-03-17 18:13:58 ERROR 2023-03-17 18:13:58 ERROR Timeout while waiting for events up to lock
2023-03-17 18:13:58 INFO Looking for magic cut-over table
2023-03-17 18:13:58 INFO Will now proceed to drop magic table and unlock tables
2023-03-17 18:13:58 INFO Dropping magic cut-over table
2023-03-17 18:13:58 INFO Dropping magic cut-over table
2023-03-17 18:13:58 INFO Dropping table db1._test_20230317181349_del
2023-03-17 18:14:58 ERROR Error 1205: Lock wait timeout exceeded; try restarting transaction
2023-03-17 18:14:58 INFO Releasing lock from db1.test, db1._test_20230317181349_del
2023-03-17 18:14:58 INFO Tables unlocked
After AllEventsUpToLockProcessed to timeout, execute the following code:
The 'drop table_test_20230317181349_del' statement is waiting for a metadata lock until it defaults to waiting for 60 seconds for the metadata lock to exit.
The code marked in red waits until the above execution ends before executing the "UNLOCK TABLES" release table
- 主要语言
- Go
- 星标
- 13.6k
- 派生
- 1.4k
- 平均合并
- 9 天 19 小时
- 30 天内合并 PR
- 1
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
github/gh-ost 的其他 Issue
-
`--resume` without `--execute` drops the ghost table it correctly skipped altering可能已有人在做 @ajm188 于 55 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 10 天内回复
-
[Suggestion] Apply simple validation to alter command可能已有人在做 @drkemp187 于 106 天前认领。 未关闭enhancement good first issue
难度 2/5 1-3 小时 新手友好度 64/100
维护者通常 10 天内回复
-
Migration hangs when --attempt-instant-ddl succeeds可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 30/100
维护者通常 10 天内回复
-
难度 4/5 3-5 天 新手友好度 42/100
维护者通常 10 天内回复
-
Atomic cut-over always fails on MySQL 9.1+: information_schema.processlist errors out (3854) while another session runs a non-BMP utf8mb4 statement可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 52/100
维护者通常 10 天内回复
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 85/100
prime-radiant-inc/evener#6325 ·
维护者通常 1 天内回复
-
team:library-maintainers
难度 2/5 1-3 小时 新手友好度 82/100
padok-team/burrito#1208 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
bazel-contrib/rules_go#4784 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 78/100
betterleaks/betterleaks#484 ·
维护者通常 1 天内回复