[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094614#comment-14094614
]
Lars Hofhansl commented on HBASE-10247:
---------------------------------------
Yep, the current semantics are sound.
Actually the issue is not that both cluster need to be active... We'll have the
issue above even with a single writer cluster only: Either we accept out of
order timestamps at the slave (when we use the timestamps of the primary) or we
accept out of order edits at the slave (when we use the slave to assign local
server TSs). The former goes against what I want to achieve the latter leads to
incorrect data.
A way around this would be to strictly order *all* edit as they are replicated,
which is very difficult as replication is decentralized (which is especially an
issue when RSs die and other take over their replication work). Synchronous
replication would by definition do that.
> 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)
