This message was deleted.
# general
s
This message was deleted.
a
For some more context, I have a namespace-wide retention policy set based on time, that I think might be naive. I set it to "four days" thinking that would be good for disaster recovery after a long weekend potentially, but now I am set to add a couple potentially chatty new topics, and I am considering my options. I know I can set topic-level policies, of course, but reading about orphaned ledgers has me wondering if that might have something to do with something I mentioned here month or so ago where there were messages in a topic that were WAY older than they needed to be.
• How do you detect such a thing? • If I see it, how can I remediate? • Is there a nuclear option (like disabling and then re-enabling) all retention and backlog policies, to get things consistent again?
d
@Hang Chen - can you provide any additional insight here?
m
Did you ever solve the orphaned ledgers issue?
I wouldn't expect changing these settings to lead to orphaned ledgers.
a
I never solved the original issue and, as far as I know, it's still there, but, given my current knowledge, I'd have to do some sort of detailed audit of every topic to know for sure.
Unless there is a better way to detect these kind of edge cases. I figure there must be a way to detect data that will never expire somehow, but I am unaware of it.
And I'm still not sure what the best course to remediate it would be, provided I found it.
I wouldn't expect changing these settings to lead to orphaned ledgers.
Yeah, and as far as I know that's a red herring, but since it seemed related and is also failure condition that is currently opaque to me, it's got me really curious about how to detect it and what symptoms it might cause.
Reading a bit more about it, it seems as if these ledgers would be untracked, which is to say invisible to pulsar, so would it be safe to say that it would really only be an issue of storage at that point?
m
When the ledgers are deleted, they should eventually get removed from bookkeeper. All of the relevant metadata is in zk if you need to verify some odd state... as always, the key is knowing where to look.