Re: Repair when a replica is Down
Hi I have intentionally posted this message to the dev mailing list instead of users list because its regarding a conscious design decision taken regarding a bug and I feel that dev team is the most appropriate team who could respond to it. Please let me know if there are better ways to get it 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://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-2290 where an intentional decision was taken to abort the repair if a replica is down. I need to understand the reasoning behind aborting the repair instead of proceeding with available replicas. I have following concerns with the approach: We say that we have a fault tolerant Cassandra system such that we can afford single node failure because RF=3 and we read/write at QUORUM.But when a node goes down and we are not sure how much time will be needed to restore the node, entire system health is in question as gc_grace_period is approaching and we are not able to run repair -pr on any of the nodes. Then there is a dilemma:Whether to remove the faulty node well before gc grace period so that we get enough time to save data by repairing other two nodes? This may cause massive streaming which may be unnecessary if we are able to bring back the faulty node before gc grace period. OR Wait and hope that the issue will be resolved before gc grace time and we will have some buffer to run repair -pr on all nodes. OR 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 node failure scenarios. I need to understand the recommeded approach too for maintaing a fault tolerant system which can handle such node failures without hiccups. ThanksAnuj
Re: Versioning policy?
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 other open source products and it would be really nice if we could streamline such things for Apache Cassandra. ThanksAnuj 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 thoughts on below points: 1. EOL of a release should be based on "most stable"/"production ready" version date rather than "GA" date of subsequent major releases. 2. I think we should have "Formal EOL Announcement" on Apache Cassandra website. 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so that users get reasonable time to upgrade. 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website EOL thread on users mailing list ended with the conclusion of raising a Wishlist JIRA but I think above points are more about working on policy and processes rather than just a wish list. ThanksAnuj Sent from Yahoo Mail on Android On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis wrote: Hi Maciek, First let's talk about the tick-tock series, currently 3.x. This is pretty simple: outside of the regular monthly releases, we will release fixes for critical bugs against the most recent bugfix release, the way we did recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases will be patched. Now, we also have three other release series currently being supported: 2.1.x: supported with critical fixes only until 4.0 is released, projected in November 2016 [2] 2.2.x: maintained until 4.0 is released 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017 I will add this information to the releases page [3]. [1] https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690pzp...@mail.gmail.com%3E [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be sunsetting deprecated features like Thrift so bumping the major version seems appropriate [3] http://cassandra.apache.org/download/ On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda wrote: > There was a discussion recently about changing the Cassandra EOL policy on > the users list [1], but it didn't really go anywhere. I wanted to ask here > instead to clear up the status quo first. What's the current versioning > policy? The tick-tock versioning blog post [2] states in passing that two > major releases are maintained, but I have not found this as an official > policy stated anywhere. For comparison, the Postgres project lays this out > very clearly [3]. To be clear, I'm not looking for any official support, > I'm just asking for clarification regarding the maintenance policy: if a > critical bug or security vulnerability is found in version X.Y.Z, when can > I expect it to be fixed in a bugfix patch to that major version, and when > do I need to upgrade to the next major version. > > [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html > [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/ > [3]: http://www.postgresql.org/support/versioning/ > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Versioning policy?
Correct, this is an open source project. If you want a Enterprise support story Datastax 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 > other open source products and it would be really nice if we could streamline > such things for Apache Cassandra. > > ThanksAnuj > > 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 thoughts on below points: > 1. EOL of a release should be based on "most stable"/"production ready" > version date rather than "GA" date of subsequent major releases. > 2. I think we should have "Formal EOL Announcement" on Apache Cassandra > website. > 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so > that users get reasonable time to upgrade. > 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website > > EOL thread on users mailing list ended with the conclusion of raising a > Wishlist JIRA but I think above points are more about working on policy and > processes rather than just a wish list. > > ThanksAnuj > > > > Sent from Yahoo Mail on Android > > On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis wrote: > Hi Maciek, > > First let's talk about the tick-tock series, currently 3.x. This is pretty > simple: outside of the regular monthly releases, we will release fixes for > critical bugs against the most recent bugfix release, the way we did > recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases > will be patched. > > Now, we also have three other release series currently being supported: > > 2.1.x: supported with critical fixes only until 4.0 is released, projected > in November 2016 [2] > 2.2.x: maintained until 4.0 is released > 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017 > > I will add this information to the releases page [3]. > > [1] > https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690pzp...@mail.gmail.com%3E > [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be > sunsetting deprecated features like Thrift so bumping the major version > seems appropriate > [3] http://cassandra.apache.org/download/ > >> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda wrote: >> >> There was a discussion recently about changing the Cassandra EOL policy on >> the users list [1], but it didn't really go anywhere. I wanted to ask here >> instead to clear up the status quo first. What's the current versioning >> policy? The tick-tock versioning blog post [2] states in passing that two >> major releases are maintained, but I have not found this as an official >> policy stated anywhere. For comparison, the Postgres project lays this out >> very clearly [3]. To be clear, I'm not looking for any official support, >> I'm just asking for clarification regarding the maintenance policy: if a >> critical bug or security vulnerability is found in version X.Y.Z, when can >> I expect it to be fixed in a bugfix patch to that major version, and when >> do I need to upgrade to the next major version. >> >> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html >> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/ >> [3]: http://www.postgresql.org/support/versioning/ > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced >
Re: Versioning policy?
I was not referring to Enterprise support here. When I said Open source "product" by mistake, I was just referring to some other Apache open source projects like Apache Cassandra where you get EOL announcements, info etc on the main Apache web site. I think all four points are very relevant in context of an Open source project and thats why I wanted to thoughts on these points. ThanksAnuj Sent from Yahoo Mail on Android On Sun, 17 Jan, 2016 at 1:43 am, Michael Kjellman wrote: Correct, this is an open source project. If you want a Enterprise support story Datastax 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 > other open source products and it would be really nice if we could streamline > such things for Apache Cassandra. > > ThanksAnuj > > 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 thoughts on below points: > 1. EOL of a release should be based on "most stable"/"production ready" > version date rather than "GA" date of subsequent major releases. > 2. I think we should have "Formal EOL Announcement" on Apache Cassandra > website. > 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so > that users get reasonable time to upgrade. > 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website > > EOL thread on users mailing list ended with the conclusion of raising a > Wishlist JIRA but I think above points are more about working on policy and > processes rather than just a wish list. > > ThanksAnuj > > > > Sent from Yahoo Mail on Android > > On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis wrote: >Hi Maciek, > > First let's talk about the tick-tock series, currently 3.x. This is pretty > simple: outside of the regular monthly releases, we will release fixes for > critical bugs against the most recent bugfix release, the way we did > recently with 3.1.1 for CASSANDRA-10822 [1]. No older tick-tock releases > will be patched. > > Now, we also have three other release series currently being supported: > > 2.1.x: supported with critical fixes only until 4.0 is released, projected > in November 2016 [2] > 2.2.x: maintained until 4.0 is released > 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017 > > I will add this information to the releases page [3]. > > [1] > https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690pzp...@mail.gmail.com%3E > [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be > sunsetting deprecated features like Thrift so bumping the major version > seems appropriate > [3] http://cassandra.apache.org/download/ > >> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda wrote: >> >> There was a discussion recently about changing the Cassandra EOL policy on >> the users list [1], but it didn't really go anywhere. I wanted to ask here >> instead to clear up the status quo first. What's the current versioning >> policy? The tick-tock versioning blog post [2] states in passing that two >> major releases are maintained, but I have not found this as an official >> policy stated anywhere. For comparison, the Postgres project lays this out >> very clearly [3]. To be clear, I'm not looking for any official support, >> I'm just asking for clarification regarding the maintenance policy: if a >> critical bug or security vulnerability is found in version X.Y.Z, when can >> I expect it to be fixed in a bugfix patch to that major version, and when >> do I need to upgrade to the next major version. >> >> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html >> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/ >> [3]: http://www.postgresql.org/support/versioning/ > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced >