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/09/2012 07:01 PM, Himanshu Vashishtha wrote:
>> First of all, I assume that it is required for replication to work correct
>> that all edits are replayed on the replica HBase cluster in the same order
>> as they were executed on the source HBase cluster. Correct?
>>
> Not really.... as it just tails the WAL at each regionserver in the
> source cluster and sends the edits to the destination cluster. The
> keyvalues are not altered while sending to the slave, so even if they
> reach out of order, they settle down there with  the same effect. They
> are in order from a source cluster regionserver's perspective, not
> from a Table instance perspective.

Thanks. I overlooked the way HBase deals with versions of key value pairs.

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.

So it is "eventually consistent", but when it is "not yet consistent"
(replication out of order and ongoing), there is no way on the replica
to know this..

thanks,
Jan

ps: sorry for the email duplicates of my original question.
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