Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> HBase replication: "in order semantics"


Copy link to this message
-
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB