> > 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? Cheers! >
