[
https://issues.apache.org/jira/browse/HBASE-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875471#comment-13875471
]
stack commented on HBASE-10070:
-------------------------------
bq. ....Is it too much to ask to change the view of what a HRI means
No. As long as we are clear what we are about.
It is not clear in HBASE-10347 that HRI's role is changed from description of
actual region to instead, description of a region 'cluster'. It needs to be
made more plain.
Regards...
{quote}
...Regarding special casing, yes there is some special casing in the way the
regions are added to the meta - create table will create all regions (if the
table was created with replica > 1), but only the primary regions will be added
to the meta. The regionserver - when it updates the meta with the location
after it opens a region invokes the API passing the replicaID as an argument -
the column names are different based on whether the replicaID is primary or
not. These are pretty much the special cases for the meta updates."...
{quote}
I went back to the design doc and it is too high level for me to 'see' the new
hbase:meta schema changes and the list of special casings. I think a
description of the new hbase:schema would help. A list of the
'special-casings' would help too but might be easier just looking at code. A
macro-level list perhaps?
Is 'replica' and 'replica id' the right term given we want to first put in
place mechanisms that can be used for more than just 'read replicas'. Region
'set' and set 'member'?
bq. This might mean tools that currently depend on the name format would break
even if the cluster is not deploying tables with replicas
Once before, we had two naming schemes in the cluster and via various tricks --
whether there is a '.' on the end -- it was possible to have the cohabit the
same cluster instance. In this case, it might not have to be so radical. We
might just relax the regex that looks at encoded name such that if we encounter
a region with more than the usual 20 bytes of md5, then those extra bytes are
set member index (no need of a delimiter -- delimiter messes up your sort which
may not be an issue if rows in hbase:meta are no longer the actual names of
regions).
> HBase read high-availability using eventually 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.1.5#6160)
