[ https://issues.apache.org/jira/browse/HBASE-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006367#comment-14006367 ]
Mikhail Antonov commented on HBASE-10070: ----------------------------------------- bq. HA is great feature, but it has nothing to do with improving read requests latency distribution. In this jira we're saying that we can't provide good latency in 99 (.999?) % cases for the following (but not limited, as there're also GC pauses etc) reason: when region replica fails (RS fails) the requests time out, or just take really long time. And this feature is addressing this aspect. So this jira aims (as I understand) to give HA (possibly stale) replicas, with added benefit of reduced latency. > HBase read high-availability using timeline-consistent region replicas > ---------------------------------------------------------------------- > > Key: HBASE-10070 > URL: https://issues.apache.org/jira/browse/HBASE-10070 > Project: HBase > Issue Type: New Feature > Reporter: Enis Soztutar > Assignee: Enis Soztutar > Attachments: HighAvailabilityDesignforreadsApachedoc.pdf > > > In the present HBase architecture, it is hard, probably impossible, to > satisfy constraints like 99th percentile of the reads will be served under 10 > ms. One of the major factors that affects this is the MTTR for regions. There > are three phases in the MTTR process - detection, assignment, and recovery. > Of these, the detection is usually the longest and is presently in the order > of 20-30 seconds. During this time, the clients would not be able to read the > region data. > However, some clients will be better served if regions will be available for > reads during recovery for doing eventually consistent reads. This will help > with satisfying low latency guarantees for some class of applications which > can work with stale reads. > For improving read availability, we propose a replicated read-only region > serving design, also referred as secondary regions, or region shadows. > Extending current model of a region being opened for reads and writes in a > single region server, the region will be also opened for reading in region > servers. The region server which hosts the region for reads and writes (as in > current case) will be declared as PRIMARY, while 0 or more region servers > might be hosting the region as SECONDARY. There may be more than one > secondary (replica count > 2). > Will attach a design doc shortly which contains most of the details and some > thoughts about development approaches. Reviews are more than welcome. > We also have a proof of concept patch, which includes the master and regions > server side of changes. Client side changes will be coming soon as well. -- This message was sent by Atlassian JIRA (v6.2#6252)