-
Notifications
You must be signed in to change notification settings - Fork 233
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
Add AAE status subsystem + finalize AAE for Riak 1.3 release #456
Conversation
Add riak_kv_entropy_info module that provides an API to keep track of AAE status such as tree build times and exchange statistics. The information is stored in a public ETS table that is owned by the riak_kv_sup. Update the AAE subsystem to call into the info module where appropriate. Add aae_status/1 as a console command in riak_kv_console that pretty prints the AAE information.
This code relies upon a fix to |
Note: When testing this for review, you'll likely want to adjust the AAE options in |
Let me describe the status output. The first output lists information about exchanges that occur for a given index.
The The second output section shows how long ago a given index's hash trees were built.
The section shows statistics about the number of keys repaired in any given
|
+1 |
Add AAE status subsystem + finalize AAE for Riak 1.3 release
This pull-request adds code to track the status of AAE as well as provides a console command for use with
riak-admin
to print out the status.This pull-request also fixes a bug with AAE, where tree build times were not persisted to disk, and therefore restarting a node would delay tree expiration. Build times are now persisted.
Finally, this pull request removes some extremely spammy log messages that were already flagged with TODOs in the source. Commenting out these messages seems like the best approach for user-experience for Riak 1.3. We can re-consider for Riak 1.4.
The approach used by the status subsystem (recomputing everything on each request for status) is rather inefficient and can easily be optimized to both cache certain values as well as update other aggregate information in real-time as status events occur. However, this is largely premature optimization for a part of code that is not critical. The current solution is straightforward and easily handles things like changing bucket N-values, changing ring ownership, etc without any special code needed (such as to flush cached values in a cached approach). Simply put, let's ship a working solution now, consider optimizing for Riak 1.4.