-Re: HBase replication: "in order semantics"
Jan Van Besien 2012-11-15, 07:54
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
Does this make sense? Or am I missing something completely?
Thanks in advance,