Adar Dembo created KUDU-2922:
--------------------------------

             Summary: Metric for WAL retention
                 Key: KUDU-2922
                 URL: https://issues.apache.org/jira/browse/KUDU-2922
             Project: Kudu
          Issue Type: Bug
          Components: consensus, metrics
    Affects Versions: 1.11.0
            Reporter: Adar Dembo


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.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to