[server] KV snapshot scheduling stops permanently after a transient snapshot-init failure
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 88/100
Hướng nghiên cứu
Bắt đầu trong fluss-server/.../kv/snapshot/PeriodicSnapshotManager.java tại triggerSnapshot(), sau đó so sánh nhánh lỗi khởi tạo với cơ chế xử lý lỗi bất đồng bộ hiện có và luồng scheduleNextSnapshot(). Xác minh rằng lỗi khởi tạo tạm thời không kết thúc chuỗi one-shot và các lần thử snapshot được tiếp tục sau khi backend hoạt động trở lại.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Search before asking
- I searched in the issues and found nothing similar.
Fluss version
main (development)
Please describe the bug
I searched in the issues and found nothing similar. Closest family:
- #2977
- #2978, A different start-time trigger, already fixed.
Motivation
A transient backend outage during snapshot initialization permanently disables KV snapshots for the affected buckets until the TabletServer restarts. The failure is silent after a single ERROR line: no retry, no metric alarm, no recovery when the backend returns.
Reproduction
- Fluss 1.0.0 (also present on
main, file is identical), 1 coordinator + 2 tablet servers,kv.snapshot.interval: 60s, S3-compatible remote storage. - Stop the object store for ~6 minutes, then restore it.
- During the outage, tablets log
Connection refusedwith AWS SDK retries; writes keep flowing (local hot path, unaffected). - After the backend returns: no new snapshot for 14+ minutes (~14 missed 60s cycles). Only
snap-1/snap-2remain (retention keeps the last two). - Restarting one tablet produces a fresh snapshot ~50s later (
snap-4), confirming the scheduler — not the backend path — was dead.
Root cause
fluss-server/.../kv/snapshot/PeriodicSnapshotManager.java, triggerSnapshot() (v1.0.0 and main identical):
try {
snapshotRunnableOptional = target.initSnapshot();
} catch (Exception e) {
LOG.error("Fail to init snapshot during triggering snapshot.", e);
return; // <-- scheduleNextSnapshot() never called
}
Scheduling is a one-shot chain (schedule(triggerSnapshot, delay) + explicit scheduleNextSnapshot()), so returning here without rescheduling breaks the chain permanently for that bucket. The async-phase failure path (whenComplete) does track retries; only the init path drops the chain.
Observed log line proving the trigger:
ERROR org.apache.fluss.server.kv.snapshot.PeriodicSnapshotManager [] - Fail to init snapshot during triggering snapshot.
followed by total silence (no further attempts, successes, or failures).
Solution
Call scheduleNextSnapshot() on the init-failure path too (ideally with backoff after consecutive failures, mirroring the existing numberOfConsecutiveFailures tracking in the async path), so a transient backend outage degrades to missed snapshots instead of a permanently dead scheduler.
Are you willing to submit a PR?
- I'm willing to submit a PR!
- Ngôn ngữ chính
- Java
- Star
- 2.2k
- Fork
- 656
- Merge trung bình
- 1 ngày 21 giờ
- Pull request đã merge (30 ngày)
- 127
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không 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 apache/fluss
-
[lake/iceberg] Reserved write-mode properties can be set and reset through their `iceberg.` keyCó thể đã có người làm @aphenix-r7 đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
apache/fluss#4658 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[common] Decimal#hashCode is inconsistent with Decimal#equalsCó thể đã có người làm @firasbouzazi đã nhận 13 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
apache/fluss#4538 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[security] PlainSaslServerProvider conflicts with Hadoop SASL provider causing authentication failureCó thể đã có người làm @xinzhang-hello đã nhận 19 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[docs] Document advertised-resource and ACL principal ignore-case optionsCó thể đã có người làm @EchoLee5 đã nhận 31 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[client] LimitBatchScanner leaks Arrow read context on log-table LIMIT scanCó thể đã có người làm @EchoLee5 đã nhận 31 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
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 82/100
apache/rocketmq-dashboard#6896 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
OpenIntegrationEngine/engine#496 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
SasanLabs/VulnerableApp#836 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement frontend
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Albertinesilva/backend-engineering-journey-java-springboot#46 ·