> Erick, a question purely as a point of curiosity.  The entire model of a
> commit log, historically (speaking in RDBS terms), depended on a notion of
> stable store. The idea being that if your data volume lost recent writes,
> the failure mode there would be independent of writes to the volume holding
> the commit log, so that replay of the commit log could generally be
> depended on to recover the missing data.  Iā€™d be curious what the C* expert
> viewpoint on that would be, with the commit log and data on the same volume.

Those are fair points so thanks for bringing them up. I'll comment from a
personal viewpoint and others can provide their opinions/feedback.šŸ‘

If you think about it, you've lost the data volume -- not just the recent
writes. Replaying the mutations in the commit log is probably insignificant
compared to having to recover the data through various ways (re-bootstrap,
refresh from off-volume/off-server snapshots, etc). The data and
redo/archive logs being on the same volume (in my opinion) is more relevant
in RDBMS since they're mostly deployed on SANs compared to the
nothing-shared architecture of C*. I know that's debatable and others will
have their own view. :)

How about you, Reid? Do you have concerns about both data and commitlog
being on the same disk? And slightly off-topic but by extension, do you
also have concerns about the default commitlog fsync() being 10 seconds?


Reply via email to