hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: HBase replication: "in order semantics"
Date Fri, 16 Nov 2012 17:24:16 GMT
You are right on the last scenario. Deleted data might permanently resurface in that case.

HBASE-4721 is an attempt to deal with that (mostly a hack, IMHO).

-- Lars

 From: Jan Van Besien <janvb@ngdata.com>
To: dev@hbase.apache.org 
Sent: Friday, November 16, 2012 3:18 AM
Subject: Re: HBase replication: "in order semantics"
On 11/15/2012 06:45 PM, lars hofhansl wrote:
> Yes. If there are failures in the source cluster the replicated data might be delivered
out of order.


> Note that you will never see partial rows applied; replication will enforce HBase's ACID
guarantee here,


> but rows might be delivered out of order, which means the ordering of deletes and puts
might change, and hence lead to *temporary* visibility of deleted data. Eventually the state
will be correct, though.

I understand that there are situations in which the reordering results in temporary visibility
of deleted data. But additionally I also think that there are (unlikely) situations which
can lead to permanent visibility of deleted data on the replica.

The situation I think of is:
- put followed by delete on source cluster
- reordering resulting in delete followed by put on replica
- delete gets executed on replica
- a major compaction happens on the replica (thus "really" deleting)
- put gets executed on the replica (thus permanently staying there)

Is there an error in my reasoning?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message