ra/browse/CASSANDRA-7304 sort of addresses
> this in 2.2+
>
>
>
>
> On Wed, Mar 14, 2018 at 11:32 AM, Madhu-Nosql
> wrote:
>
>> Rahul,
>>
>> Tomstone caused is on the Application driver side so even though they are
>> not using some of the Columns
n objects.
>
> --
> Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On Mar 13, 2018, 2:18 PM -0400, Madhu-Nosql , wrote:
>
> We assume that's becoz of nulls
>
> On Tue, Mar 13, 2018 at 12:58 PM, Rahul Singh <
> rahul.xavier.si...@gmail.com> wr
We assume that's becoz of nulls
On Tue, Mar 13, 2018 at 12:58 PM, Rahul Singh
wrote:
> Are you writing nulls or does the data cycle that way?
>
> --
> Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On Mar 13, 2018, 11:48 AM -0400, Madhu-Nosql ,
; Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On Mar 13, 2018, 11:29 AM -0400, Madhu-Nosql ,
> wrote:
>
> I got few ways to Drop Tombstones- Chos Monkey/Zombie Data mainly to avoid
> Data
> Resurrection (you deleted data it will comes back in future)
>
>
I got few ways to Drop Tombstones- Chos Monkey/Zombie Data mainly to avoid Data
Resurrection (you deleted data it will comes back in future)
I am thinking of below options, let me know if you have any best practice
for this
1.using nodetool garbagecollect
2.only_purge_repaired_tombstones
3.At Tab
Kenneth,
For AWS -EC2Snitch(if DC in Single Region)
For Google- Better go with GossipingPropertyFileSnitch
Thanks,
Madhu
On Mon, Mar 12, 2018 at 6:31 PM, Kenneth Brotman <
kenbrot...@yahoo.com.invalid> wrote:
> Quick question: If you have one cluster made of nodes of a datacenter in
> AWS and
