[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094472#comment-14094472
]
Andrew Purtell commented on HBASE-10247:
----------------------------------------
bq. More importantly. Server-side-only TSs cannot work with replication! When
region servers fail in a source cluster edit may reach the slave cluster out of
order.
At some point we might have synchronous replication cross cluster. Discussed
elsewhere on other JIRAs. (Or if not actively we should file one.) In the
meantime we will have this class of problem in many areas if replication is
active *and* both clusters are hosting active applications. I don't think that
invalidates the single cluster use case for server-side-only TSes. It also
doesn't invalidate, or at least it doesn't change current semantics, of use
cases where a passive remote cluster collects update for disaster recovery.
> Client promises about timestamps
> --------------------------------
>
> Key: HBASE-10247
> URL: https://issues.apache.org/jira/browse/HBASE-10247
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Lars Hofhansl
> Priority: Minor
> Fix For: 0.99.0, 2.0.0
>
> Attachments: 10247-do-not-try-may-eat-your-first-born-v2.txt,
> 10247.txt
>
>
> This is to start a discussion about timestamp promises declared per table of
> CF.
> For example if a client promises only monotonically increasing timestamps (or
> no custom set timestamps) and VERSIONS=1, we can aggressively and easily
> remove old versions of the same row/fam/col from the memstore before we
> flush, just by supplying a comparator that ignores the timestamp (i.e. two KV
> just differing by TS would be considered equal).
> That would increase the performance of counters significantly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
