[
https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243882#comment-14243882
]
James Taylor commented on HBASE-12672:
--------------------------------------
No, I mean it could still be asynchronously applied on the secondary
cluster, but it wouldn't return back to the client until it made it to
the point of submitting the change to the secondary cluster in a
durable queue (but before the change is actually applied). That way,
the secondary cluster would necessarily have to be up (i.e. it
wouldn't be a second point of failure). Only the queue would have to
be writable to. What's the protocol now?
> 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)
