Error current heartbeatlag (9223372036.85s) is too high
维护者通常 10 天内回复
还没有人认领这个 Issue。
评估
调研方向
首先检查 gh-ost 1.1.6 中的 TimeSinceLastHeartbeatOnChangelog() 和 heartbeat-lag 路径，然后使用 MariaDB 11.4 及所述时区设置重现该报告。确定时间戳为何仍为 0001-01-01，并验证已完成的迁移报告的是真实的 heartbeat lag，而不是 9223372036.85 秒。
由索引模型根据 Issue 内容生成。
描述
Hi all, I want to ask about gh-ost migration.
When I run gh-ost migration on my virtual machine and the progress reached 100%, it got error log current heartbeatlag 9223372036.85s is too high, it needs to be less than both --max-lag-millis (1.50s) and --cut-over-lock-timeout-seconds (3.00) to continue.
Here is the current specification:
- gh-ost version is 1.1.6
- using MariaDB version 11.4
What I have done are:
- Upgrading the gh-ost version from 1.1.5 into 1.1.6
- Running the gh-ost command without
--max-lag-millis - Reseting the master database to refresh the replica
- Run
ANALYZE TABLEto refresh the performance schema - Also I have set the timezone setting into UTC+7 to comply with my current timezone in Indonesia by running this SQL:
SET GLOBAL time_zone = '+07:00';andSET time_zone = '+07:00';
So I'm curious about the printed value of TimeSinceLastHeartbeatOnChangelog(), I decide to debug it on my local by print its value, but it shows 0001-01-01 00:00:00 +0000 UTC, hence the heartbeat lag value become extremely huge.
Do you have any idea why this happens? Will appreciate any help given for this issue.
Thanks in advance!
Attachments:
- 主要语言
- 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 天内回复