Re: Repair scheduling tools
> 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.