yugabyte/yugabyte-db

[DocDB] After deleting snapshot_schedule, there is about few seconds (about 5 to 10 seconds) of latency in reflecting in list_snapshot_schedules.

Open

#13,438 建立於 2022年7月26日

在 GitHub 查看
 (0 留言) (0 反應) (0 負責人)C (1,003 fork)batch import
good first issuekind/bugpriority/medium

倉庫指標

Star
 (8,229 star)
PR 合併指標
 (平均合併 17天 21小時) (30 天內合併 92 個 PR)

描述

Jira Link: DB-3059

Description

Steps:

  1. Create a snapshot schedule.
  2. Delete snapshot_schedule.
  3. List all snapshot schedules via list_snapshot_schedules.

Observation:

If we keep on hitting list_snapshot_schedules, it will list deleted one as well for around 5 to 10 seconds. There is latency. Is this async call? Should we make it sync call?

貢獻者指南

研究方向
該問題報告了刪除快照排程與從 list snapshot schedules 中消失之間存在 5-10 秒的延遲。這表明存在非同步傳播延遲。為解決此問題，請調查刪除和列出程式碼路徑，可能位於 `yb/master/backends/catalog manager.cc` 或 `yb/master/snapshot coordinator.cc` 等檔案中。尋找任何背景任務或最終一致性機制。檢查是否存在在返回客戶端之前同步確認刪除的方法。同時，審查快照排程刪除的任何現有測試，以了解預期行為。
技術棧
c
領域
database
議題類型
錯誤
難度面向新貢獻者的預計實作難度，1 表示很小改動，5 表示專家級工作。
2
預計時間有經驗貢獻者完成調查、實作、測試並準備 pull request 的粗略時間範圍。
1-3 小時
活動狀態議題目前的可參與程度：新鮮、活躍、陳舊、阻塞或等待維護者輸入。
新近可參與
清晰度議題是否清楚說明預期改動、驗收標準和下一步。
清晰
前置要求
Git
新手友善度1-100 的估計分數，表示該議題對首次貢獻者的友善程度。
40