[
https://issues.apache.org/jira/browse/CASSANDRA-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joaquin Casares updated CASSANDRA-3696:
---------------------------------------
Description:
On Cassandra-1.0.5:
1. Create a node in C* with a fresh installation and create a keyspace on that
node with one column family -
CREATE KEYSPACE test
WITH placement_strategy = 'SimpleStrategy'
and strategy_options={replication_factor:1};
use test;
create column family cf1;
2. Insert values into cf1 -
set cf1[ascii('k')][ascii('c')] = ascii('v');
get cf1[ascii('k')];
=> (column=63, value=v, timestamp=1325689630397000)
Returned 1 results.
3. update the strategy options from simple to networktopology with
{Cassandra:1, Backup:1}
4. read from cf1 to make sure the options change doesn't affect anything -
consistencylevel as LOCAL_QUORUM;
get cf1[ascii('k')];
=> (column=63, value=v, timestamp=1325689630397000)
Returned 1 results.
5. start a second node in the Backup datacenter
6. read from cf1 again (on the first node) -
consistencylevel as LOCAL_QUORUM;
get cf1[ascii('k')];
Returned 0 results.
After about 60 seconds, "get cf1[ascii('k')]" started to return results again.
Also, when running at a CL of ONE on 1.0's head, we were able to see issues as
well.
But, if more than one node was added to the second datacenter, then
replication_strategy is changed, it seems okay.
was:
On Cassandra-1.0.5:
1. Create a node in C* with a fresh installation and create a keyspace on that
node with one column family -
CREATE KEYSPACE test
WITH placement_strategy = 'SimpleStrategy'
and strategy_options={replication_factor:1};
use test;
create column family cf1;
2. Insert values into cf1 -
set cf1[ascii('k')][ascii('c')] = ascii('v');
get cf1[ascii('k')];
=> (column=63, value=v, timestamp=1325689630397000)
Returned 1 results.
3. update the strategy options from simple to networktopology with
{Cassandra:1, Backup:1}
4. read from cf1 to make sure the options change doesn't affect anything -
consistencylevel as LOCAL_QUORUM;
get cf1[ascii('k')];
=> (column=63, value=v, timestamp=1325689630397000)
Returned 1 results.
5. start a second node in the Backup datacenter
6. read from cf1 again (on the first node) -
consistencylevel as LOCAL_QUORUM;
get cf1[ascii('k')];
Returned 0 results.
After about 60 seconds, "get cf1[ascii('k')]" started to return results again.
Also, when running at a CL of ONE on 1.0's head, we were able to see issues as
well.
> Adding another datacenter's node results in 0 rows returned on first
> datacenter
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-3696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3696
> Project: Cassandra
> Issue Type: Bug
> Reporter: Joaquin Casares
>
> On Cassandra-1.0.5:
> 1. Create a node in C* with a fresh installation and create a keyspace on
> that node with one column family -
> CREATE KEYSPACE test
> WITH placement_strategy = 'SimpleStrategy'
> and strategy_options={replication_factor:1};
> use test;
> create column family cf1;
> 2. Insert values into cf1 -
> set cf1[ascii('k')][ascii('c')] = ascii('v');
> get cf1[ascii('k')];
> => (column=63, value=v, timestamp=1325689630397000)
> Returned 1 results.
> 3. update the strategy options from simple to networktopology with
> {Cassandra:1, Backup:1}
> 4. read from cf1 to make sure the options change doesn't affect anything -
> consistencylevel as LOCAL_QUORUM;
> get cf1[ascii('k')];
> => (column=63, value=v, timestamp=1325689630397000)
> Returned 1 results.
> 5. start a second node in the Backup datacenter
> 6. read from cf1 again (on the first node) -
> consistencylevel as LOCAL_QUORUM;
> get cf1[ascii('k')];
> Returned 0 results.
> After about 60 seconds, "get cf1[ascii('k')]" started to return results
> again.
> Also, when running at a CL of ONE on 1.0's head, we were able to see issues
> as well.
> But, if more than one node was added to the second datacenter, then
> replication_strategy is changed, it seems okay.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
