[
https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242143#comment-14242143
]
Andrew Purtell commented on HBASE-12672:
----------------------------------------
It would be fantastic to have this capability in HBase, but I won't expect a
patch forthcoming on this JIRA right away, it's a hard problem.
In a naive implementation, the source would wait for the sink to ack before
returning control back to the client. Performance and scalability of the
cluster would be bounded by what is most likely a WAN link. True, I'm making an
assumption, but I think it would hold for the majority of possible use cases.
WAN links don't have the reliability of datacenter networks. Every blip on the
WAN would be a period of unavailability in the source cluster. Downtime in the
sink would mean downtime in the source too, which would defeat the probable
goal of service resiliency behind the introduction of replication in the first
place. For something workable (resilient and performant) look to examples like
Megastore and Spanner that make consensus work over wide area networks.
> 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)
