Re: Addressing the symptoms, but not the cause?

(Note: I work at Basho (makers of Riak), and was the lead developer on this new Active Anti-Entropy feature.)

Riak is a database. You put data in, you get data out. There are no inherent inconsistencies in Riak, nor any built-in symptom that needs to be repaired.

Yes, Riak is an eventually consistent database, rather than a strongly consistent database. The AP option rather than the CP option from CAP. But, this has nothing to do with durability or data safety. AP vs CP determine the types of applications that a given database can support. Certain applications can tolerate eventual consistency and can use Riak, others can't and should use another database. Or wait until Riak supports strong consistency in addition to eventual consistency later this year.

The new Active Anti-Entropy (AAE) feature has nothing to do with eventual vs strong consistency. It's a self-healing feature designed to address hardware failure and other scenarios outside the control of the database. It's similar to RAID, but built into your database.

Riak is a fault-tolerant, replicated database. When you write data, it's stored to multiple machines (3 by default). Thus, you can lose machines and still have readable replicas. If a machine fails, you're going to end up with missing data (replace failed hardware w/ new, empty hardware) or divergent data (replace + restore from recent, but not 100% current backup). When you read an object, the request will be sent to all replicas, returning the non-missing/non-divergent (ie. correct) data. Riak, however, notices that one of the replicas is missing or divergent and asynchronously repairs it from the data on the other replicas.

The issue with this approach is that data is only repaired on reads. The new AAE feature augments this approach to provide a lightweight background process that's constantly verifying replicas and repairing things as necessary. Thus, even cold data that is never read is verified and repaired. The aim is to make sure all data is repaired before any other nodes fail. Sure, multiple failures could happen before everything is repaired and you're toast. This is no different than any other database (log replay/recovery) / RAID. There's always a chance additional disks will fail while you're in the process of rebuilding your RAID array. It's just statistically rare enough that we can all still sleep at night.

In any case, AAE isn't designed to solve an inherent problem with Riak. It's designed to help regenerate your data when hard drives, nodes, etc fail. It's also designed to detect silent data corruption (faulty hard drive / controller), an issue that effects all databases.

In short, AAE is similar to the protection provided by triple-mirrored ZFS, but at the node rather than hard drive level. ZFS maintains a hash tree for all data stored in the filesystem. On every read, the replicas are verified against the hash stored elsewhere on disk. If there's a mismatch, the bad replica is repaired from replicas on the other disks. As was famously discussed around the time ZFS appeared on the scene, this helps protect against silent data corrupt / bit rot (eg. when your hard drive, disk controller, etc corrupt data w/o any indication). The problem is that this verification only happens when data is read, thus cold data is never checked. The solution: a cron job that runs 'zfs scrub' periodically to verify all data on disk. Riak has similarly always done a verify/repair check on every read. The new AAE feature adds a smart, lightweight 'zfs scrub' equivalent that continuously verifies all data all the time.

Riak is designed to be an operations-friendly, fault-tolerant database. A database designed to easily scale-out as needed, that can tolerate multiple node failures and network partitions (eg. switch failures / split brain scenarios). Adding built-in self-healing / protection against silent data corruption from faulty hardware was a logic next step. Of course, Riak is a harder database to develop for, requiring eventually-consistent tolerant algorithms/designs. But, that's the great part about the "new database" or so-called NoSQL (*cringe*) movement: there's different products for different use cases. As a co-worker of mine use to say, thesedays databases are like D&D classes: use the right one for the quest; sometimes you need a rogue, other times a mage is best.

(Big Brother, cause AAE is watching your data...)