[
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)
