Re: Why a READ REPAIR ?

> > Perhaps this is super obvious but I need a confirmation as you say “…not > subsequent reads for other data unrelated to the read being repaired…” > > But this is subsequent reads to the _*same*_ partition key > > So to be more explicit > > READ 1 with Local Quorum : SELECT * FROM products

Re: Connect java application to Cassandra in Kubernetes

> > Erick, even if we give service as a contact point datastax driver will > calculate IPs of topology to connect the cluster. So I think as John > proposed in answer to similar question, after driver initialization in case > of total outage of Cassandra cluster, bouncing of application is the

Re: Records in table after deleting sstable manually

Thanks Jeff. Appreciate your reply. as you said , looks like some there were entries in commitlogs and when cassandra was brought up after deleting sstables, data from commitlog replayed. May be next time I will let the replay happen after deleting sstable and then truncate table using CQL. This

Re: Records in table after deleting sstable manually

The data probably came from either hints or commitlog replay. If you use `truncate` from CQL, it solves both of those concerns. On Tue, Aug 11, 2020 at 8:42 AM Kunal wrote: > HI, > > We have a 3 nodes cassandra cluster and one of the table grew big, around > 2 gb while it was supposed to be

Records in table after deleting sstable manually

HI, We have a 3 nodes cassandra cluster and one of the table grew big, around 2 gb while it was supposed to be few MBs. During nodetool repair, one of the cassandra went down. Even after multiple restart, one of the node was going down after coming up for few mins. We decided to truncate the

Re: Why a READ REPAIR ?

Hi Tobias READ2 will not be blocked by READ repair of READ1. Regards Manish On Tue, Aug 11, 2020 at 6:02 PM Tobias Eriksson wrote: > Thanx Erick, > > Perhaps this is super obvious but I need a confirmation as you say “…not > subsequent reads for other data unrelated to the read being

Re: Why a READ REPAIR ?

Thanx Erick, Perhaps this is super obvious but I need a confirmation as you say “…not subsequent reads for other data unrelated to the read being repaired…” But this is subsequent reads to the _same_ partition key So to be more explicit READ 1 with Local Quorum : SELECT * FROM products WHERE id =

Re: Connect java application to Cassandra in Kubernetes

Erick, even if we give service as a contact point datastax driver will calculate IPs of topology to connect the cluster. So I think as John proposed in answer to similar question, after driver initialization in case of total outage of Cassandra cluster, bouncing of application is the only option.

Re: Why a READ REPAIR ?

> > If a READ triggers a READ REPAIR, and then if we do an additional READ > would then that BLOCK until the “first” READ REPAIR would be done ? > > -Tobias > Not all read repairs are blocking RRs (aka foreground RRs). There are also background RRs which by definition are non-blocking because

Re: Why a READ REPAIR ?

If a READ triggers a READ REPAIR, and then if we do an additional READ would then that BLOCK until the “first” READ REPAIR would be done ? -Tobias From: Jeff Jirsa Reply to: "user@cassandra.apache.org" Date: Tuesday, 11 August 2020 at 07:30 To: cassandra Subject: Re: Why a READ REPAIR ?