[
https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244674#comment-14244674
]
Andrew Purtell commented on HBASE-12672:
----------------------------------------
bq. eventually as in "if the secondary cluster was switched over to we could
drain any durable queues containing replicated values before starting to take
traffic."
This is an interesting idea and it would reasonably handle the case where
source to sink communication over the WAN is reliable and relatively low
latency but maybe the queue of edits for application at the sink site is backed
up due to local issues. What it won't handle is (IMO, a quite common case)
where the WAN link is not reliable and not low latency.
> 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)
