Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-2922

Metric for WAL retention

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.11.0
    • Fix Version/s: None
    • Component/s: consensus, metrics
    • Labels:
      None

      Description

      When users run out of disk space in --fs_wal_dir, the first question is usually "which replica caused this to happen?" A per-replica retention metric would help here. Unlike RAM anchored, WAL segments (or bytes) retained isn't easily observable via other mechanisms. It's also tough to calculate this via CLI tooling, as one would need to open and read all WAL segments to figure out whether the corresponding data has been flushed.

      Bonus points if we can break down the metric into "retained for durability" and "retained for slow follower catch-up". This isn't as important though because --log_segment_size_mb and --log_max_segments_to_retain can be used to calculate an upper bound on the amount retained for catch-up.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              adar Adar Dembo

              Dates

              • Created:
                Updated:

                Issue deployment