On Mon, Nov 22, 2010 at 11:52 AM, Todd Lipcon <t...@lipcon.org> wrote:
> Not quite. The replica synchronization code is pretty messy, but basically > it will take the longest replica that may have been synced, not a quorum. > > i.e the guarantee is that "if you successfully sync() data, it will be > present after replica synchronization". Unsynced data *may* be present after > replica synchronization. > > But keep in mind that recovery is blocking in most cases - ie if the RS is > writing to a pipeline and waiting on acks, and one of the nodes in the > pipeline dies, then it will recover the pipeline (without the dead node) and > continue syncing to the remaining two nodes. The client is still blocked at > this point. > I see. So it sounds like my statement #1 was wrong. Will the RS ever timeout the write and fail in the face of not being able to push it to HDFS? Is it correct to say: Once a write is issued to HBase, it will either catistrophicly fail (i.e. disconnect), in which case the write with either have failed or succeeded, and if it succeeded, future reads will always show that write? As opposed to Cassandra, which in all configurations where reads allow a subset of all nodes, can "fail" a write while having the write show a temporary period of inconsistency (depending on who you talk to) followed by the write either applying or not applying depending on whether or not it actually wrote a single node during the "failure to meet the write consistency request"? Does Cassandra have any return result which distinguishes between these two states: 1 - your data was not written to any nodes (true failure) 2 - your data was written to at least 1 node, but not enough to meet your write-consistency count ?
