Migration hangs when --attempt-instant-ddl succeeds
I maintainer di solito rispondono entro 10 giorni
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 30/100
Direzione di ricerca
Start with Migrate() in go/logic/migrator.go, where the instant-DDL branch returns without reading ghostTableMigrated, then follow onChangelogStateEvent and notifyListeners to see where listenersMutex is held during the blocking send. The binlog side is shouldDecodeRowsEvent in the event streamer, reached through BinlogSyncer.Close() in finalCleanup. Done means the instant-DDL success path returns without hanging, with a test covering that short-circuit.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Overview
A migration run with --attempt-instant-ddl against a server that can apply the
ALTER instantly applies it, logs Success! table ... migrated instantly, and then
never returns. gh-ost hangs until it is killed.
Reproduced on master (dd44453f) and on v1.1.11.
Why
Migrate() short-circuits on the instant-DDL path: on success it calls
finalCleanup(), runs the OnSuccess hook and returns, so it never reads
<-mgtr.ghostTableMigrated.
Three goroutines then form a cycle:
-
The changelog listener parks on the
GhostTableMigratedsend in
onChangelogStateEvent.ghostTableMigratedis unbuffered and the
instant-DDL path never reads it, so the send blocks. It is wrapped in
base.SendWithContext, which only unblocks on context cancellation — and
nothing cancels the context here, precisely becauseMigrate()has not
returned. The listener is invoked fromnotifyListeners, which holds
listenersMutexacross the synchronous call, so the mutex stays held for as
long as the send is parked. -
The binlog parser goroutine (go-mysql's
BinlogSyncer.onStream) calls
EventsStreamer.shouldDecodeRowsEventthroughRowsEventDecodeFuncand
blocks taking that samelistenersMutex. -
BinlogSyncer.Close(), reached fromfinalCleanup()→
EventsStreamer.Close(), ends inb.wg.Wait()and waits for that parser
goroutine, which is never coming back.
Step 2 is what makes the cycle reachable. shouldDecodeRowsEvent was introduced
by #1699 ("Don't parse binlog events of unrelated tables", first released in
v1.1.11); it put listenersMutex on the binlog parser's goroutine, so a listener
parked while holding that mutex now stalls the parser directly, and with it
BinlogSyncer.Close().
--attempt-instant-ddl defaults to off and the short-circuit has no test
coverage, which is presumably why this has not been reported before. We hit it in
a downstream consumer that passes the flag for every migration, where every ALTER
MySQL could apply instantly hung.
Reproduction
Any instant-applicable ALTER on MySQL 8.0 with the flag set, e.g.
gh-ost --host=... --database=test --table=testing \
--alter='ADD COLUMN author varchar(255)' \
--attempt-instant-ddl --allow-on-master --execute
The column is added, Success! ... migrated instantly is logged, and the process
does not exit.
Fix
PR to follow: scope listenersMutex to the listener lookup in notifyListeners,
and give ghostTableMigrated a one-slot buffer.
- Lingua principale
- Go
- Stelle
- 13.6k
- Fork
- 1.4k
- Merge medio
- 9g 19h
- PR unite (30g)
- 1
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di github/gh-ost
-
`--resume` without `--execute` drops the ghost table it correctly skipped alteringForse già presa @ajm188 l’ha presa 55 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 10 giorni
-
[Suggestion] Apply simple validation to alter commandForse già presa @drkemp187 l’ha presa 106 giorni fa. Apertaenhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
github/gh-ost#1431 · 4 commenti ·
I maintainer di solito rispondono entro 10 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
I maintainer di solito rispondono entro 10 giorni
-
Atomic cut-over always fails on MySQL 9.1+: information_schema.processlist errors out (3854) while another session runs a non-BMP utf8mb4 statementForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
github/gh-ost#1780 · 1 commento ·
I maintainer di solito rispondono entro 10 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
I maintainer di solito rispondono entro 10 giorni
Tutte le issue di github/gh-ost
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
prime-radiant-inc/evener#6325 ·
I maintainer di solito rispondono entro 1 giorno
-
team:library-maintainers
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
padok-team/burrito#1208 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
bazel-contrib/rules_go#4784 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
betterleaks/betterleaks#484 ·
I maintainer di solito rispondono entro 1 giorno