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 21:10:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244781#comment-14244781
] 

Andrew Purtell commented on HBASE-12672:
----------------------------------------

Thinking on this a bit more:
{quote}
bq. only once the edit is applied on the secondary we make it visible in the primary
How does that work when HBase clients, upon returning from a write, do and should expect to
read their own writes immediately?
{quote}
It would be strange, but we could make clients aware of the special aspect of the table, thus
advising them the nature of reality has changed, and let them (i.e. the HBase client library)
build synchronous semantics on top: write something, then spin until the last written edit
becomes visible, then return control back to the application. We'd need to ensure the sink
reliably acks edits and checks that the source acked the ack, and retransmit acks if not,
for reliable signal delivery for making "pending" edits visible.

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

Mime
View raw message