You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Adar Dembo (Jira)" <ji...@apache.org> on 2019/08/20 18:57:00 UTC
[jira] [Created] (KUDU-2922) Metric for WAL retention
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)