[Bug] Cut-over may self-deadlock (Error 1205) behind Cloud Proxy / ProxySQL due to session-level lock visibility inconsistency

Offen
  • Stimmt etwas nicht?
#1,659 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 10 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
42/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
go, mysql
Bereich
databases

Rechercherichtung

Beginnen Sie mit der cut-over-Sperren-Orchestrierung und der Sitzungs-/Verbindungsverwaltung von gh-ost und reproduzieren Sie dann Error 1205 über einen ProxySQL-like- oder Cloud-Proxy bei null Traffic. Definieren und testen Sie einen optionalen Single-Session-Cut-over-Modus und verifizieren Sie, dass das atomare Umbenennen ohne Timeout abgeschlossen wird, während das bestehende Verhalten unverändert bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Go
Sterne
13.6k
Forks
1.4k
Ø Merge
9 T. 19 Std.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/gh-ost

Alle Issues in github/gh-ost

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.