Open binarytemple opened 9 years ago
nerophon
commented
9 years ago 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?
binarytemple
commented
8 years ago Never good practice anyway to have too many bucket-types. In fact, if that causes problems the user is probably doing it wrong anyway.
binarytemple
commented
8 years ago 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.
Basho-JIRA
commented
7 years ago 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]
pyrrho
commented
7 years ago This has been, at least partially, incorporated into #907. That PR adds a section that loops over Bucket Types listed with riak-admin bucket-types list and prints the configuration set for each Type.
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.