hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
Date Thu, 11 Dec 2014 04:38:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242134#comment-14242134

Lars Hofhansl commented on HBASE-12672:

Frankly, I am not a fan of this.

# Synchronous replication creates two points of failure. If the target cluster is down we'll
render the primary unusable, as everything would be waiting replication to finish since it
is synchronous. That is true if we make this by table, but it would be same, target is down,
primary is no longer usable for this table. At best we can timeout on the replication and
pass this timeout as an failed write error back to the client.
# This would be a completely new code path. Right now we tail the WALs, that necessarily happens
after the write has already finished. We'd need to invent a new way for this (possibly through
coprocessor hooks).

Some database do synchronous replication to alleviate read load. HBase can already scale by
just adding more boxes (granted, though, read of a particular data item would be served by
a single server only - except for region replicas).

Now, maybe there is a place for this doing intra-datacenter replication to keep a copy of
the data in separate cluster (maybe for map/reduce), ever there I'd ask: Why does it have
to synchronous?

Everything in HBase is idempotent. Phoenix adds more of that "database'y stuff", which is
awesome, but comes with a loss of idempotency - such as in the issue raised above. I think
we'd be better served finding other solutions (stateless sequences for example), that is easier
to reason about and more resilient against failure.

None of this means we can/should not do this.

> Support optionally replicating a table synchronously
> ----------------------------------------------------
>                 Key: HBASE-12672
>                 URL: https://issues.apache.org/jira/browse/HBASE-12672
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: James Taylor
>            Priority: Minor
> Sometimes a table may contain state in which it's crucial to know that replication occurred
before continuing with the update. Though this would mean that you'd block updates to this
table if your secondary cluster was unavailable, that might be a tradeoff that a user would
be willing to make. An example would be in support of SQL sequences. See this thread (http://s.apache.org/fTP)
and PHOENIX-1422 for more discussion and context.

This message was sent by Atlassian JIRA

View raw message