Why gh-ost set time_zone to UTC when applying DML events
I maintainer di solito rispondono entro 10 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
Direzione di ricerca
Inizia dal codice sorgente Go, in ApplyDMLEventQueries, e verifica come imposta time_zone. Riproduci il caso segnalato con MySQL 5.7.26, SYSTEM/Shanghai e un evento DML con un timestamp, quindi confronta i valori interrogati. Il lavoro è completo quando è stata concordata una spiegazione e, se il comportamento è involontario, è disponibile una modifica testata o la documentazione del comportamento previsto del fuso orario.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Env
gh-ost: 1.1.2mysql: 5.7.26time_zone: system(ShangHai)
Bug
Mysql server is configured with time_zone=system and the server's time zone is Shanghai. The problem I encountered was that during the gh-ost run, after the insert statement involved the timestamp time field was successfully inserted, when the data was queried again, the time field increased by 8 hours.
question
Looking at the source code, I found that time_zone = '+00:00' is defined in the ApplyDMLEventQueries function, which is equal to the UTC time zone. Because insert is written in UTCtime zone, but select is read in SYSTEM time zone, the time field is increased by 8 hours.
My question is why the UTC time zone is set when applying dml event instead of using the default time zone configuration?
- 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
-
Migration hangs when --attempt-instant-ddl succeedsForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
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
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