The region replica feature came in so as to reduce the MTTR and so increase the data availability. When the master region containing RS dies, the clients can read from the secondary regions. But to keep one thing in mind that this data from secondary regions will be bit out of sync as the replica is eventual consistent. Because of this said reason, change client so as to share the load across diff RSs might be tough.
-Anoop- On Sun, Feb 12, 2017 at 8:13 AM, jeff saremi <jeffsar...@hotmail.com> wrote: > Yes indeed. thank you very much Ted > > ________________________________ > From: Ted Yu <yuzhih...@gmail.com> > Sent: Saturday, February 11, 2017 3:40:50 PM > To: user@hbase.apache.org > Subject: Re: On HBase Read Replicas > > Please take a look at the design doc attached to > https://issues.apache.org/jira/browse/HBASE-10070. > > Your first question would be answered by that document. > > Cheers > > On Sat, Feb 11, 2017 at 2:06 PM, jeff saremi <jeffsar...@hotmail.com> wrote: > >> The first time I heard replicas in HBase the following thought immediately >> came to my mind: >> To alleviate the load in read-heavy clusters, one could assign Region >> servers to be replicas of others so that the load is distributed and there >> is less pressure on the main RS. >> >> Just 2 days ago a colleague quoted a paragraph from HBase manual that >> contradicted this completely. Apparently, the replicas do not help with the >> load but they actually contribute to more traffic on the network and on the >> underlying file system >> >> Would someone be able to give us some insight on why anyone would want >> replicas? >> >> And also could one easily change this behavior in the HBase native Java >> client to support what I had been imagining as the concept for replicas? >> >> >> thanks >>
