Re: URGENT: CASSANDRA-14092 causes Data Loss

:20 PM IST, Anuj Wadehra wrote: Hi Paulo, Thanks for coming out with the Emergency Hot Fix!!  The patch will help many Cassandra users in saving their precious data. I think the criticality and urgency of the bug is too high. How can we make sure that maximum Cassandra users are alerted

Design Proposal for Auditing feature in Cassandra

Hi, Apache Cassandra doesn't provides an auditing feature. As Database auditing is critical for any production level database like Apache Cassandra, our team is keen on designing & implementing this feature in Apache Cassandra.  I have submitted the Design proposal for "Database Auditing" feature

Re: URGENT: CASSANDRA-14092 causes Data Loss

ncy hot fix to prevent silent data loss while the permanent fix is not in place. 2018-01-26 6:27 GMT-02:00 Anuj Wadehra : > Hi Jeff, > One correction in my last message: "it may be more feasible to SUPPORT (not > extend) the 20 year limit in Cassandra in 2.1/2.2". > I co

Re: URGENT: CASSANDRA-14092 causes Data Loss

he JIRA. This will attract the due attention of all Cassandra users. ThanksAnuj On Friday 26 January 2018, 12:47:18 PM IST, Anuj Wadehra wrote: Hi Jeff, Thanks for the prompt action! I agree that patching an application MAY have a shorter life cycle than patching Cassandra in produc

Re: URGENT: CASSANDRA-14092 causes Data Loss

ff Jirsa > On Jan 25, 2018, at 9:07 PM, Jeff Jirsa wrote: > > Patches welcome. > > -- > Jeff Jirsa > > >> On Jan 25, 2018, at 8:15 PM, Anuj Wadehra >> wrote: >> >> Hi Paulo, >> >> Thanks for looking into the issue on priority.

Re: URGENT: CASSANDRA-14092 causes Data Loss

rdan : >>> If you aren’t getting an error, then I agree, that is very bad.  Looking >> at the 3.0 code it looks like the assertion checking for overflow was >> dropped somewhere along the way, I had only been looking into 2.1 where you >> get an assertion error that fail

Re: URGENT: CASSANDRA-14092 causes Data Loss

01) maximum (63072)" ThanksAnuj On Friday 26 January 2018, 12:11:03 AM IST, J. D. Jordan wrote: Where is the dataloss?  Does the INSERT operation return successfully to the client in this case?  From reading the linked issues it sounds like you get an error client side. -Jerem

URGENT: CASSANDRA-14092 causes Data Loss

Hi, For all those people who use MAX TTL=20 years for inserting/updating data in production, https://issues.apache.org/jira/browse/CASSANDRA-14092 can silently cause irrecoverable Data Loss. This seems like a certain TOP MOST BLOCKER to me. I think the category of the JIRA must be raised to BLO

Re: Restore Snapshot

I mistakenly posted it on dev mailing list. Please ignore. Posting it on user mailing list. :) ThanksAnuj  Sent from Yahoo Mail on Android On Tue, Jun 27, 2017 at 7:01 PM, Anuj Wadehra wrote: Hi, I am curious to know how people practically use Snapshot restore provided that snapshot

Restore Snapshot

Hi, I am curious to know how people practically use Snapshot restore provided that snapshot restore may lead to inconsistent reads until full repair is run on the node being restored ( if you have dropped mutations in your cluster). Example:9 am snapshot taken on all 3 nodes10 am mutation drop on

Re: Wrapping up tick-tock

Hi, Now that we are rethinking versioning and release frequency, there exists an opportunity to make life easier for Cassandra users. How often mailing lists are discussing: "Which Cassandra version is stable for production?"OR"Is x version stable?" Your release version should indicate your confid

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

ssues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved <https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved> > On Nov 10

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

Hi, We need to understand that time is precious for all of us. Even if a developer has intentions to contribute, he may take months to contribute his first patch or may be longer. Some common entry barriers are: 1. Difficult to identify low hanging fruits. 30 JIRA comments on a ticket and a ne

Re: A proposal to move away from Jira-centric development

Hi, I think tracking things in a tool would be better than having mailing lists+JIRA. To make feature JIRAs easier to comprehend, we can close every JIRA discussion with an attached Design proposal (mandatory). Once design is frozen and complete, one can start with the implementation.  Not sure

Re: [VOTE] Release Apache Cassandra 3.8

Hi Michael, Just found an issue in Changes.txt.  Add cross-DC latency metrics (CASSANDRA-11596) should be Track message latency across DCs CASSANDRA-11569. ThanksAnujSent from Yahoo Mail on Android On Thu, 21 Jul, 2016 at 3:18 AM, Michael Shuler wrote: I propose the following artifacts for

Re: Possible Bug: bucket_low has no effect in STCS

Should I raise JIRA ?? Or some develiper with knowledge of STCS could confirm the bug ?? Anuj Sent from Yahoo Mail on Android On Tue, 14 Jun, 2016 at 12:52 PM, Anuj Wadehra wrote: Can any developer confirm the issue? ThanksAnuj Sent from Yahoo Mail on Android On Mon, 13 Jun

Re: Possible Bug: bucket_low has no effect in STCS

Can any developer confirm the issue? ThanksAnuj Sent from Yahoo Mail on Android On Mon, 13 Jun, 2016 at 11:15 PM, Anuj Wadehra wrote: Hi, I am trying to understand the algorithm of STCS. As per my current understanding of the code, there seems to be no impact of setting bucket_low in

Possible Bug: bucket_low has no effect in STCS

Hi, I am trying to understand the algorithm of STCS. As per my current understanding of the code, there seems to be no impact of setting bucket_low in the STCS compaction algorithm. Moreover, I see some optimization. I would appreciate if some designer can correct me or confirm that it's a bug

Re: [Proposal] Mandatory comments

I think this is very basic. If its not followed till now, we should do that now on.Just a suggestion. So,there should be a rule and may be a code review checklist point to verify that "quality" of comments is ok and comments are sufficient. Regarding, high level comments, I feel that they are won

Re: Criteria for upgrading to 3.x releases in PROD

x to 4.x - IOW, upgrade to 3.x well before 3.x EOL. -- Jack Krupansky On Sat, Apr 23, 2016 at 3:28 PM, Anuj Wadehra < anujw_2...@yahoo.co.in.invalid> wrote: > Jonathan, > I understand you point. In my perspective, people in production usually > prefer stability over features and

Re: Criteria for upgrading to 3.x releases in PROD

simplistic answer like "version X is the most stable" (are you willing to use unsupported releases?  what about emergency-fix-only?  what features can you not live without?) so we're intentionally resisting the urge to oversimplify the situation. On Mon, Apr 18, 2016 at 8:25 P

Re: Criteria for upgrading to 3.x releases in PROD

data rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo <http://linkedin.com/in/carlosjuzarterolo>* Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649 www.pythian.com On Mon, Apr 18, 2016 at 7:12 PM, Anuj Wadehra < anujw_2...@yahoo.co.in.invalid> wrote: &g

Re: Criteria for upgrading to 3.x releases in PROD

r use case, ops team, and organization. This is a personal decision and not one for *thousands* of others on this mailing list to make for you. best, kjellman > On Apr 18, 2016, at 10:54 AM, Anuj Wadehra > wrote: > > Hi All, > For last several months, the "most stable version

Re: Criteria for upgrading to 3.x releases in PROD

ce between 3.0.x and 3.x, so risk levels are around the same, so long as you limit yourself to only the features present in 3.0.x. Either way, make sure to properly test whatever release you go for in staging first, as Michael says, and you’ll be alright. --  AY On 11 April 2016 at 18:42:31, A

Re: Criteria for upgrading to 3.x releases in PROD

Can someone help me with this one? ThanksAnuj Sent from Yahoo Mail on Android On Sun, 10 Apr, 2016 at 11:07 PM, Anuj Wadehra wrote: Hi, Tick-Tock release strategy in 3.x was a good intiative to ensure frequent & stable releases. While odd releases are supposed to get all the bug f

Criteria for upgrading to 3.x releases in PROD

Hi, Tick-Tock release strategy in 3.x was a good intiative to ensure frequent & stable releases. While odd releases are supposed to get all the bug fixes and should be most stable, many people like me, who got used to the comforting "production ready/stable" tag on Apache website,  are still rel

Re: EOL for COMPACT STORAGE

I would appreciate if someone from Dev team could reply? ThanksAnuj Sent from Yahoo Mail on Android On Sun, 31 Jan, 2016 at 7:23 pm, Anuj Wadehra wrote: Hi, Is there any plan to completely phase out COMPACT STORAGE table format such that backward compatability is broken in future

EOL for COMPACT STORAGE

Hi, Is there any plan to completely phase out COMPACT STORAGE table format such that backward compatability is broken in future? ThanksAnuj

Re: 3.1 status?

I agree with the thought of not recommending any production ready version. If something is not production ready, it should ideally be release candidate and when GA happens, it should implicitly mean stable as it is assumed that the GA is only done for production ready releases. ThanksAnuj Sent

Re: Repair when a replica is Down

was responsible(owner) cant be repaired as 1 out of 5 replicas is down. This will put entire system health in question just because of single node failure. ThanksAnuj Sent from Yahoo Mail on Android On Tue, 19 Jan, 2016 at 11:12 pm, Anuj Wadehra wrote: Hi Tyler, I think the scenario

Re: Repair when a replica is Down

system health would get impacted as multiple nodes are not repairing with a single node failure. ThanksAnujSent from Yahoo Mail on Android On Tue, 19 Jan, 2016 at 10:48 pm, Anuj Wadehra wrote: There is a JIRA  Issue https://issues.apache.org/jira/browse/CASSANDRA-10446 .  But its open with

Re: Repair when a replica is Down

improvement. Can we change its priority so that it gets appropriate attention? ThanksAnuj On Tue, 19 Jan, 2016 at 10:35 pm, Tyler Hobbs wrote: On Tue, Jan 19, 2016 at 10:44 AM, Anuj Wadehra wrote: Consider a scenario where I have a 20 node clsuter, RF=5, Read/Write Quorum, gc grace period=20

Re: Repair when a replica is Down

On Tue, 19 Jan, 2016 at 9:44 pm, Tyler Hobbs wrote: On Fri, Jan 15, 2016 at 12:06 PM, Anuj Wadehra wrote: > Increase the gc grace period temporarily. Then we should have capacity > planning to accomodate the extra storage needed for extra gc grace that may > be needed in case of nod

Re: Versioning policy?

Is that assumption valid? It will certainly help to get such insights before hand on Apache site so that community users can prepare their upgrade road map. ThanksAnuj On Sunday, 17 January 2016 12:48 AM, Anuj Wadehra wrote: Hi Jonathan It would be really nice if you could sha

Re: Versioning policy?

tax has an Enterprise option for you. > On Jan 16, 2016, at 11:19 AM, Anuj Wadehra wrote: > > Hi Jonathan > > It would be really nice if you could share your thoughts on the four points > raised regarding the Cassandra EOL process. I think similar things happen for > ot

Re: Versioning policy?

Sent from Yahoo Mail on Android On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra wrote: Hi Jonathan, Thanks for the crisp communication regarding the tick tock release & EOL. I think its worth considering some points regarding EOL policy and it would be great if you can share your thought

Re: Repair when a replica is Down

addressed. ThanksAnuj Sent from Yahoo Mail on Android On Fri, 15 Jan, 2016 at 11:36 pm, Anuj Wadehra wrote: Hi  We are on 2.0.14,RF=3 in a 3 node cluster. We use repair -pr . Recently, we observed that repair -pr for all nodes fails if a node is down. Then I found the JIRA  https

Repair when a replica is Down

Hi  We are on 2.0.14,RF=3 in a 3 node cluster. We use repair -pr . Recently, we observed that repair -pr for all nodes fails if a node is down. Then I found the JIRA  https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-2290 where an intentional decision was taken to abort the re

Re: Versioning policy?

Hi Jonathan, Thanks for the crisp communication regarding the tick tock release & EOL. I think its worth considering some points regarding EOL policy and it would be great if you can share your thoughts on below points: 1.  EOL of a release should be based on "most stable"/"production ready" vers

Re: Behavior of nodetool stop compaction

: Hello, could you paste the exception and also show what is the cassandra version running? jason On Sun, May 24, 2015 at 2:12 AM, Anuj Wadehra wrote: > Firing nodetool stop command prints CompactionInterruptedException > stacktrace. > > 1. Exception stacktrace gives an impressio

Re: Behavior of nodetool stop compaction

: Hello, could you paste the exception and also show what is the cassandra version running? jason On Sun, May 24, 2015 at 2:12 AM, Anuj Wadehra wrote: > Firing nodetool stop command prints CompactionInterruptedException > stacktrace. > > 1. Exception stacktrace gives an impression

Behavior of nodetool stop compaction

Firing nodetool stop command prints CompactionInterruptedException stacktrace. 1. Exception stacktrace gives an impression of killing a compaction forcefully, is nodetool stop COMPACTION a clean way to interrupt an ongoing MAJOR compaction? 2. How the logic works? When nodetool stop is fired to

Is deletion of compactions_in_progress files safe?

I need to understand how compaction Algorithm works at high level. 1. What is the significance of systems.compactions_in_progress table and files in compactions_in_progress directory.  2. We are on 2.0.3. We frequently face scenarios where Cassandra fails to restart with Exception regarding unfi

Re: Repair with -pr and -local after CASSANDRA-7450

th -pr and -local after CASSANDRA-7450 CASSANDRA-7450 is for version 2.1.1 and higher. So it is not available in 2.0.x. On Mon, May 18, 2015 at 1:43 PM, Anuj Wadehra wrote: > Hi, > This is regarding execution of repair -pr in local DC. > CASSANDRA-7313 disabled using pr with local optio

Contribution to Cassandra Community and Branching Strategy

Hi, I want to submit patch for Cassandra JIRA tickets. I have some questions: 1. As per http://wiki.apache.org/cassandra/HowToContribute, we need to clone trunk and provide patch on that. So, I need to understand how this patch is going to be merged in 2.0.x and 2.1.x ? 2. Where can I get the d

Repair with -pr and -local after CASSANDRA-7450

Hi, This is regarding execution of repair -pr in local DC. CASSANDRA-7313 disabled using pr with local option. Later, CASSANDRA-7450 allowed it. But when I look at the code of Cassandra 2.0.13, I see that using pr with local is still illegal: How to do Repair with pr and local DC option in 2.0.13

Re: Drawbacks of Major Compaction now that Automatic Tombstone Compaction Exists

I havent got much response regarding this on user list..so posting it on dev list too.. Thanks Anuj Wadehra Sent from Yahoo Mail on Android From:"Anuj Wadehra" Date:Tue, 14 Apr, 2015 at 7:05 am Subject:Drawbacks of Major Compaction now that Automatic Tombstone Compaction Exists

Drawbacks of Major Compaction now that Automatic Tombstone Compaction Exists

split the big sstable but as new sstables were of same size they are again compacted into single huge table once Cassandra was started after executing sstablesplit. Thanks Anuj Wadehra

Impact of removing compactions_in_progress folder

any other aspect? Thanks Anuj Wadehra

Run Mixed Workload using two instances on one node

Hi, We are trying to Decouple our Reporting DB from OLTP. Need urgent help on the feasibility of proposed solution for PRODUCTION. Use Case: Currently, our OLTP and Reporting application and DB are same. Some CF are used for both OLTP and Reporting while others are solely used for Reporting.Ev