New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
riak-debug should include dump of bucket-type information [JIRA: RIAK-1988] #767
Comments
Seconded. However we must consider the case where there a lot of bucket-types. How many is it practical to list (including configuration)? i.e. what's the overhead, does it bloat the size of debug-output? |
Never good practice anyway to have too many bucket-types. In fact, if that causes problems the user is probably doing it wrong anyway. |
FYI - just dug up this old gist ... very amateur ha ha but enough info to write an Erlang script to dump out the bucket-type info. |
So's it's been recorded, this week I started the process of updating riak-debug in a few ways. Gathering meaningful bucket (type) property data is high on the TODO list. I had CLISERV-32 assigned to myself, so I'd be happy to take this task if that would be appropriate. It may take me a while to produce any meaningful changes, though, as I'll be working on this between normal CSE activities. [posted via JIRA by Drew Pirrone-Brusse] |
This has been, at least partially, incorporated into #907. That PR adds a section that loops over Bucket Types listed with |
We have a need to include the bucket-type information in riak-debug, for example, where diagnosing the case where both DVV and last_write_wins are enabled.
Back when buckets were the only mechanism, it was easy, just decode the ring-file and extract the custom bucket information from there.
But bucket-type information isn't stored in the ring-file, it now lives in a secondary location - '/cluster_meta', stored in DETS database files.
If we can't be bothered writing something to iterate the bucket-type stuff, and dump as text - we could just dump the contents of the /metadata directory then decode the DETS files on our side using an Erlang snippet.
The text was updated successfully, but these errors were encountered: