hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Van Besien <ja...@ngdata.com>
Subject Re: HBase replication: "in order semantics"
Date Thu, 15 Nov 2012 07:54:13 GMT
Hi all,

On 11/12/2012 10:15 AM, Jan Van Besien wrote:
> It does however still mean that it is possible to see rows on the
> replica in a state that never occurred on the original HBase cluster, in
> case put (or even delete) operations are not replicated in original
> order and a client is reading the "latest" state.

Can anybody confirm or deny my above statement? I would like to know 
whether my understanding of the replication feature is correct or not. 

Additionally, I do think there might still be another problem with the 
correctness guarantees of replication when edits arrive on the replica 
"out of order" (which can happen AFAIK when a region server moves and 
thus new edits for the same region are for a while potentially 
replicated in parallel with older entries of that region).

Say that a put was followed by a delete, but the edits get reordered on 
the replica, thus first issuing the delete, then the put.

Normally, it should be ok. The delete marker will be written on the 
replica and then the put, but the versions of the key/values in the put 
are older, thus the delete marker will still "win" when reading back the 

However, what if in between the delete and the put, a major compaction 
happens. This major compaction cleans up the delete marker, so in that 
case, the put will "win". Is this a situation in which the replica will 
be incorrect?

Does this make sense? Or am I missing something completely?

Thanks in advance,

View raw message