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 <[email protected]> To: [email protected] 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. ok. > Note that you will never see partial rows applied; replication will enforce > HBase's ACID guarantee here, ok. > 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? thanks, Jan
