Hi Demai,
I thought making the client communicate with Central Server
frequently may not be efficient. In case of replication, I can do that
periodically in bulk.
On 7 April 2014 22:00, Demai Ni nid...@gmail.com wrote:
I looks to me that. You like to have the small clusters
Manthosh,
not sure doing replication periodically is the right way to go. I assume
you will manually start/stop replication from Master?
anyway, if it fits your business needs, give it a shoot. Let's know how it
goes.
Cheers.
Demai
On Wed, Apr 9, 2014 at 6:10 AM, Manthosh Kumar T
My use case is that I need to replicate between two geographically distant
clusters. In the simplest form, I have several geographically distant
clients that needs to add data to a geographically distant centralized
HBase server. So, I thought I'll maintain a small cluster at each client
and make
I looks to me that. You like to have the small clusters located close to
the client, and then use the smaller clusters as Masters. So there will be
multi-Masters and one-Slave cluster setup. And the one-Slave cluster is the
centralized and large HBase server.
Well, it works. But I don't get the
Can't figure out solution to achieve this behavior using existing means in
HBase immediately.
But it seems not that hard to implement it by changing some code, a rough
thought is to filter out delete entries when pushing entries to the according
replication peer and this behavior can be made
If you add a coproc on the destination cluster and ask it to reject all the
deletes, that might do the trick, but you might end up with some issues at
the end if you want to do some maintenance in the target cluster...
2014-04-04 4:26 GMT-04:00 冯宏华 fenghong...@xiaomi.com:
Can't figure out
agree about the suggestion above. just like to chime in a bit more.
One question, how do you like to treat the 'put' on the existing row? well,
it is a delete + addition to some degree.
If go to the coproc route, maybe better not to use replication at all.
Basically, you can have two tables:
