cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Morishita (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-9111) SSTables originated from the same incremental repair session have different repairedAt timestamps
Date Mon, 24 Aug 2015 12:59:46 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Yuki Morishita updated CASSANDRA-9111:
--------------------------------------
    Fix Version/s:     (was: 3.0.0 rc1)
                   3.0 beta 2

> SSTables originated from the same incremental repair session have different repairedAt
timestamps
> -------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9111
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9111
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: prmg
>             Fix For: 3.0 beta 2
>
>         Attachments: CASSANDRA-9111-v0.txt, CASSANDRA-9111-v1.txt
>
>
> CASSANDRA-7168 optimizes QUORUM reads by skipping incrementally repaired SSTables on
other replicas that were repaired on or before the maximum repairedAt timestamp of the coordinating
replica's SSTables for the query partition.
> One assumption of that optimization is that SSTables originated from the same repair
session in different nodes will have the same repairedAt timestamp, since the objective is
to skip reading SSTables originated in the same repair session (or before).
> However, currently, each node timestamps independently SSTables originated from the same
repair session, so they almost never have the same timestamp.
> Steps to reproduce the problem:
> {code}
> ccm create test
> ccm populate -n 3
> ccm start
> ccm node1 cqlsh;
> {code}
> {code:sql}
> CREATE KEYSPACE foo WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
3};
> CREATE TABLE foo.bar ( key int, col int, PRIMARY KEY (key) ) ;
> INSERT INTO foo.bar (key, col) VALUES (1, 1);
> exit;
> {code}
> {code}
> ccm node1 flush;
> ccm node2 flush;
> ccm node3 flush;
> nodetool -h 127.0.0.1 -p 7100 repair -par -inc foo bar
> [2015-04-02 21:56:07,726] Starting repair command #1, repairing 3 ranges for keyspace
foo (parallelism=PARALLEL, full=false)
> [2015-04-02 21:56:07,816] Repair session 3655b670-d99c-11e4-b250-9107aba35569 for range
(3074457345618258602,-9223372036854775808] finished
> [2015-04-02 21:56:07,816] Repair session 365a4a50-d99c-11e4-b250-9107aba35569 for range
(-9223372036854775808,-3074457345618258603] finished
> [2015-04-02 21:56:07,818] Repair session 365bf800-d99c-11e4-b250-9107aba35569 for range
(-3074457345618258603,3074457345618258602] finished
> [2015-04-02 21:56:07,995] Repair command #1 finished
> sstablemetadata ~/.ccm/test/node1/data/foo/bar-377b5540d99d11e49cc09107aba35569/foo-bar-ka-1-Statistics.db
~/.ccm/test/node2/data/foo/bar-377b5540d99d11e49cc09107aba35569/foo-bar-ka-1-Statistics.db
~/.ccm/test/node3/data/foo/bar-377b5540d99d11e49cc09107aba35569/foo-bar-ka-1-Statistics.db
| grep Repaired
> Repaired at: 1428023050318
> Repaired at: 1428023050322
> Repaired at: 1428023050340
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message