[jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously

["Lars Hofhansl (JIRA)" <ji...@apache.org>]

    [ 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
(v6.3.4#6332)