> > I personally would rather see improvements to reaper and supporting reaper > so the repair tool improvements aren't tied to Cassandra releases. If we > get to a place where the repair tools are stable then figuring out how to > bundle for the best install makes sense to me. >
I view the design we've proposed as taking many of the core ideas of Datastax Repair Service and Reaper, adding in production experience from Netflix (see the resiliency points and e.g. how remote JMX is inherently insecure and unreliable) and harmonizing them with Cassandra's shared nothing design. A few Reaper developers have already made really good contributions to the design document and we will certainly be taking Reaper's experience into account as we try to move this forward. > If we add things that will support reaper other repair solutions could also > take advantage. > I strongly believe that continuous, always on, repair is too important to leave to an external tool as it impacts the fundamental correctness of the database. Without continuous repair you can have data loss, data resurrection, and violations of quorum-quorum read after write consistency. -Joey
