Why gh-ost set time_zone to UTC when applying DML events
Maintainer thường phản hồi trong vòng 10 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu trong mã nguồn Go tại ApplyDMLEventQueries và kiểm tra cách nó thiết lập time_zone. Tái hiện trường hợp MySQL 5.7.26 được báo cáo với SYSTEM/Shanghai và một sự kiện DML có timestamp, sau đó so sánh các giá trị được truy vấn. Công việc được xem là hoàn tất khi có một lời giải thích được thống nhất và, nếu hành vi này là ngoài ý muốn, có một thay đổi đã được kiểm thử hoặc tài liệu mô tả hành vi múi giờ dự kiến.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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?
- Ngôn ngữ chính
- Go
- Star
- 13.6k
- Fork
- 1.4k
- Merge trung bình
- 9 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/gh-ost
-
`--resume` without `--execute` drops the ghost table it correctly skipped alteringCó thể đã có người làm @ajm188 đã nhận 56 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 10 ngày
-
[Suggestion] Apply simple validation to alter commandCó thể đã có người làm @drkemp187 đã nhận 106 ngày trước. Đang mởenhancement good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
github/gh-ost#1431 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 10 ngày
-
Migration hangs when --attempt-instant-ddl succeedsCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
Maintainer thường phản hồi trong vòng 10 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 10 ngày
-
Atomic cut-over always fails on MySQL 9.1+: information_schema.processlist errors out (3854) while another session runs a non-BMP utf8mb4 statementCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
github/gh-ost#1780 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 10 ngày
Tất cả issue của github/gh-ost
Issue tương tự
-
type:bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
nightgauge/nightgauge#3266 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area: ai-models priority: normal
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
prime-radiant-inc/evener#6325 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
team:library-maintainers
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
padok-team/burrito#1208 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
bazel-contrib/rules_go#4784 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày