Improve interaction between AAE and K/V deletion #478
Conversation
This change ensures that AAE does not attempt to continually repair deleted keys that an AAE hashtree believes still exist.
AAE already buffers writes and submits them as a single write-batch to LevelDB for better performance. Since deletes are also valid batch operations, this change buffers deletes alongside writes and submits all operations as a single write-batch as necessary. This change also fixes a potential bug in the previous approach that could reorder a write to happen after a delete, even if the delete occured after the write -- thus reviving a dead hash.
|
code looks fine, any testing suggestions? |
|
was about to ask same question re: testing. +1 to code, clearly fixes potential bug with deletions getting re-ordered/lost. |
|
Easiest way to test is to change the code to occasionally drop things. Was planning on writing an intercept or meck to do this, but didn't get around to it. But, easy enough to just modify the code (that's how I tested things). Take this line: Change to something like (randomly dropping 2/3 AAE deletes): (random:uniform(3) == 1) orelse riak_kv_index_hashtree:delete(BKey, State#state.hashtrees),Write a bunch of data. Then delete said data. Should see repairs start happening (some vnodes saw deletes, others did not). But, repairs should eventually stop after enough rehashing calls fix things up. If you do similar modification + test against master / 1.3.0, you'll see the repairs continue forever. |
|
confirmed described behavior in local test. +1 |
This pull-request improves AAE's handling around object deletion.
First, the pull-request changes the rehash logic in
riak_kv_vnodeto delete AAE hashes if an object is found to be missing. Thus, if a K/V delete fails to update the relevant AAE hashtree, the hashtree will be fixed on the first repair. Without this change, AAE could continually attempt to repair keys that have been deleted without informing the relevant AAE hashtree. This is scenario is hard to trigger in practice, but it's better to be safe as the fix is easy and straightforward.Second, this pull-request changes the AAE hashtrees to buffer deletes using the same logic used for buffering writes. Thus, both deletes and writes are buffered and submitted to LevelDB as a single batch operation. As previously shown, write-batching is necessary to make AAE have low impact on the cluster, thus this change is also important for users that frequently delete data.