hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12672) Support optionally replicating a table synchronously
Date Fri, 12 Dec 2014 19:42:13 GMT

    [ 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

View raw message