[
https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244650#comment-14244650
]
James Taylor commented on HBASE-12672:
--------------------------------------
That's not what I meant, but it's a good idea. I was looking for a stronger
guarantee of replication (only for these "special" tables) in that once the
server returns to the client, the client knows that the secondary cluster will
have that change (regardless of what happens to the primary cluster). In other
words, if the primary cluster were to get hit by a meteor right after the
client received the newly increment value, it'd be guaranteed that the
secondary cluster would *eventually* see the value. And by *eventually*, I
don't mean when the primary cluster comes back up, but *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." It's not as
strong a contract as synchronous replication, as we wouldn't need it to be
synchronous. We just would need a guarantee that it'll be applied to the
secondary cluster before the primary cluster returns back to the client.
> 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)
