Re: A keyspace with RF=3, Cluster with 3 RACS, CL=LQ: No Data on First Attempt, but 1 Row Aftwards

[Jeff Jirsa]

Sounds like you're writing at ONE and reading at LOCAL_QUORUM.

If you call your hosts A,B,C

Your write lands on B

If your query hits A and C, you return 0 rows.
If your query hits A and B or B and C, you return 1 row AND (as a side
effect) the row is copied to either A or C (depending on which pair is in
the query).



On Tue, Apr 23, 2019 at 7:44 AM Fd Habash  wrote:

> Cluster setup …
>
>- C* 2.2.8
>- Three RACs, one DC
>- Keyspace with RF=3
>- RS = Network topology
>
>
>
> At CL=LQ …
>
>
>
> I get zero rows on first attempt, and one row on the second or third. Once
> found, I always get the row afterwards.
>
>
>
> Trying to understand this behavior …
>
>
>
> First attempt, my read request hits a RAC that simply does not have the
> data. Subsequent attempts hit another RAC that has it which triggers a read
> repair causing the row to be returned consistently afterwards. Is this
> correct?
>
>
>
> If a coordinator picks a node in the same RAC and the node does not have
> the data on disk, is it going to stop there and return nothing even though
> the row does exist on another RAC?
>
>
>
> If anti-entropy repair has completed successfully on the entire cluster
> ‘repair -pr’, why is this still happening?
>
>
>
>
>
> 
> Thank you
>
>
>

RE: A keyspace with RF=3, Cluster with 3 RACS, CL=LQ: No Data on FirstAttempt, but 1 Row Aftwards

[Fd Habash]

Any ideas, please? 


Thank you

From: Fd Habash
Sent: Tuesday, April 23, 2019 10:38 AM
To: user@cassandra.apache.org
Subject: A keyspace with RF=3, Cluster with 3 RACS, CL=LQ: No Data on 
FirstAttempt, but 1 Row Aftwards

Cluster setup …
- C* 2.2.8
- Three RACs, one DC
- Keyspace with RF=3
- RS = Network topology 

At CL=LQ …

I get zero rows on first attempt, and one row on the second or third. Once 
found, I always get the row afterwards. 

Trying to understand this behavior …

First attempt, my read request hits a RAC that simply does not have the data. 
Subsequent attempts hit another RAC that has it which triggers a read repair 
causing the row to be returned consistently afterwards. Is this correct?

If a coordinator picks a node in the same RAC and the node does not have the 
data on disk, is it going to stop there and return nothing even though the row 
does exist on another RAC?

If anti-entropy repair has completed successfully on the entire cluster ‘repair 
-pr’, why is this still happening? 



Thank you

Re: Unpair cassandra datacenters

[Kunal]

Thanks Sandeep for your reply. Let me try out the steps you suggested. I
will let you know. Appreciate your help.


Regards,
Kunal Vaid

On Mon, Apr 22, 2019 at 4:18 PM Sandeep Nethi 
wrote:

> Hi Kunal,
>
> The simple solution for this case would be as follows,
>
> 1. Run *Full repair.*
> 2. Add firewall to block network on port 7000(,7001 if ssl enabled)
> between two datacenter nodes.
> 3. Check the status of cassandra cluster from both data centers, each DC
> must show down node status of another DC nodes after the firewall change.
> 4. Change replication factor for all keyspaces on each data center.
> 5. Start decommissioning nodes from each datacenter (Should be removenode
> in this case).
> 6. Update seeds list on each datacenter to local datacenter nodes and
> perform a rolling restart.
>
> Hope this helps, Try to test this scenario on non-prod system first.
>
> Thanks,
> Sandeep
>
> On Tue, Apr 23, 2019 at 11:00 AM Kunal  wrote:
>
>> HI Marc,
>>
>> Appreciate your prompt response.
>>
>> Yes we are starting datacenter B from scratch. We tried using cluster
>> name change on side B and it works but our requirement says we can not
>> change cluster name because during our product's major or patch release,
>> the scripts expect cluster name to be the same.
>> .
>> On datacenter B , we are changing the seeds nodes. On datacenter A , we
>> are changing the seeds nodes in cassandra.yml but that will be picked up
>> during cassandra restart only but we can not have downtime for datacenter
>> A. It has to be up all the time.
>>
>>
>> Regards,
>> Kunal Vaid
>>
>>
>> On Mon, Apr 22, 2019 at 3:49 PM Marc Selwan 
>> wrote:
>>
>>> Hi Kunal,
>>>
>>> Did you edit the cassandra.yaml file in each data center to remove the
>>> seed nodes? On which ever data center is starting from scratch (I think
>>> it's B in your case), you may want to also change the cluster name.
>>>
>>> Best,
>>> *Marc Selwan | *DataStax *| *PM, Server Team *|* *(925) 413-7079* *|*
>>> Twitter 
>>>
>>> *  Quick links | *DataStax  *| *Training
>>>  *| *Documentation
>>> 
>>>  *| *Downloads 
>>>
>>>
>>>
>>> On Mon, Apr 22, 2019 at 3:38 PM Kunal  wrote:
>>>
 Hi Friends,

 I need small help in unpairing two datacenters.
 We have 2 datacenters (say A and B ) with 3 nodes in each datacenter.
 We want to remove one whole data center (B) (3 nodes) from the other one
 (B). basically, want to unpair both datacenter and want to use them both
 individually.
 We are trying this using nodetool decommission and it is removing the 3
 nodes from B datacenter. But when we are trying to bring up datacenter B to
 use it separately from Datacenter A, it is joining back to datacenter A. We
 noticed in debug.log, nodes from datacenter A keeps looking for nodes in
 datacenter B and getting connection refused error when the nodes of
 datacenter B are down, but as soon as nodes comes back, they are joining to
 the cluster.
 We don't want nodes from datacenter B to join datacenter A once they
 are decommissioned.

 Can you please let me know if i am missing anything.

 Thanks in advance.

 Regards,
 Kunal Vaid

>>>
>>
>> --
>>
>>
>>
>> Regards,
>> Kunal Vaid
>>
>

-- 



Regards,
Kunal Vaid

A keyspace with RF=3, Cluster with 3 RACS, CL=LQ: No Data on First Attempt, but 1 Row Aftwards

[Fd Habash]

Cluster setup …
- C* 2.2.8
- Three RACs, one DC
- Keyspace with RF=3
- RS = Network topology 

At CL=LQ …

I get zero rows on first attempt, and one row on the second or third. Once 
found, I always get the row afterwards. 

Trying to understand this behavior …

First attempt, my read request hits a RAC that simply does not have the data. 
Subsequent attempts hit another RAC that has it which triggers a read repair 
causing the row to be returned consistently afterwards. Is this correct?

If a coordinator picks a node in the same RAC and the node does not have the 
data on disk, is it going to stop there and return nothing even though the row 
does exist on another RAC?

If anti-entropy repair has completed successfully on the entire cluster ‘repair 
-pr’, why is this still happening? 



Thank you

Re: insert into ... select statement

[cclive1601你]

you can use cassandra trigger

xiaobo  于2019年4月23日周二 下午1:23写道：

> Hi,
>
> Can we use the result from a select statement to insert into another table
> directlly like other RDBMS in cassandra?
>
> Thanks.
>


-- 
you are the apple of my eye !