[Bug] Cut-over may self-deadlock (Error 1205) behind Cloud Proxy / ProxySQL due to session-level lock visibility inconsistency
メンテナーはふだん 10 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
gh-ost の cut-over ロックのオーケストレーションとセッション/接続処理から始め、次にトラフィックがゼロの状態で ProxySQL-like または cloud proxy を介して Error 1205 を再現します。オプションの single-session cut-over モードを定義してテストし、既存の動作を変更せずにアトミックな rename が timeout なしで完了することを検証します。
索引モデルが issue の本文から書いたものです。
説明
Environment
MySQL: 8.0+ (Cloud RDS: Tencent Cloud / Alibaba Cloud)
gh-ost: 1.0.49
Topology: MySQL accessed through cloud proxy / load balancer (e.g. ProxySQL-like architecture)
Description In a cloud-native deployment where MySQL is accessed via a proxy layer, gh-ost repeatedly fails during cut-over with:
Error 1205: Lock wait timeout exceeded
This occurs even under very low or zero application traffic, and with no observable long-running transactions.
Under the same zero-traffic conditions, a manual atomic RENAME TABLE old TO old_del, ghost TO old succeeds immediately.
Observed Behavior
gh-ost enters cut-over
lock orchestration retries/yields
eventually exits with lock wait timeout (1205)
Expected Behavior Cut-over should complete successfully under no-contention conditions, similar to the manual atomic RENAME TABLE.
Hypothesis / Possible Root Cause gh-ost cut-over uses multiple sessions (e.g. one session holding LOCK TABLES WRITE, another issuing RENAME TABLE).
When routed through a proxy, these sessions may not share lock state/ordering semantics exactly as expected (session split-brain / lock visibility inconsistency), causing the RENAME session to wait on locks effectively held by gh-ost’s own companion session.
This can look like a self-deadlock pattern and ends in timeout/yield.
Suggested Improvement Add an optional mode for proxy/cloud-RDS environments, e.g.:
--single-session-cut-over
that executes cut-over lock + atomic rename in a single session/connection, avoiding multi-session lock orchestration dependency.
- 主要言語
- Go
- スター
- 13.6k
- フォーク
- 1.4k
- 平均マージ
- 9日 19時間
- マージ済み PR（30日）
- 1
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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
github/gh-ost#1431 · コメント 4 件 ·
メンテナーはふだん 10 日以内に返信
-
Migration hangs when --attempt-instant-ddl succeeds対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 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対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
github/gh-ost#1780 · コメント 1 件 ·
メンテナーはふだん 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 日以内に返信