问题
we're having some weird things happening with a cleanup cronjob and riak:
the objects we store (postboxes) have a 2i for modification date (which is a unix timestamp). there's a cronjob running freqently deleting all postboxes that have not been modified within 180 days. however we've found evidence that postboxes that some (very little) postboxes that were modified in the last three days were deleted by this cronjob. After reviewing and debugging several times over every line of code, I am confident, that this is not a problem of the cronjob.
- I also traced back all delete calls to that bucket - and no one else is deleting objects there.
- Of course I also checked with Riak to read the postboxes with r=ALL: they're definitely gone. (and they are stored with w=QUORUM)
- I also checked the logs: updating the post boxes did succeed (there were no errors reported back from the write operations)
This leaves me with two possible causes for this:
- riak loses data (which I am not willing to believe that easily)
- the secondary indexes are corrupt and queries to them return wrong keys
So my questions are:
- Can 2is actually break?
- Is it possible to verify that?
- Am I missing something completely different?
Cheers, Matthias
回答1:
Secondary index queries in Riak are coverage queries, which means that they will only use one of the stored replicas, and not perform a quorum read.
As you are writing with w=QUORUM, it is possible that one (or more) of the replicas may not get updated if you have n_val set to 3 or higher while the operation still is deemed successful. If this is the one selected for the coverage query, you could end up deleting based on the old value. In order to avoid this, you will need to perform updates with w=ALL.
来源：https://stackoverflow.com/questions/24882953/riak-are-my-2is-broken