The Scandit team shares their Cassandra upgrade process from 0.6.x to latest 1.0.x:

After extensive testing, we found that it fit our needs and decided to use the 0.6.0 release for our first roll out. Over the next 12 months, we kept upgrading our cluster until we reached 0.6.13, which was the last release in the 0.6.x branch.

In the meantime, Cassandra was evolving at an amazing speed. Many cool new features, such as secondary indices, CQL and schema support were added. Since we were very happy with our deployment, we moved a little slower and skip the 0.7.x releases. Now that 1.0.x has been around for a few months, we decided it was time to upgrade. Because the list of changes between the two versions was fairly long, we did the upgrade in two steps: First from 0.6.13 to 0.8.7 and then from 0.8.7 to 1.0.8.

Original title and link: Cassandra: How to Upgrade an Early Cassandra Cluster - (NoSQL database©myNoSQL)

via: http://www.scandit.com/2012/03/29/tech-how-to-upgrade-path-for-an-early-cassandra-cluster/

Jay Kreps¹:

I have come around to the view that the real core difficulty of these systems is operations, not architecture or design. Both are important but good operations can often work around the limitations of bad (or incomplete) software, but good software cannot run reliably with bad operations. […] I really think there is really only one thing to talk about with respect to reliability: continuous hours of successful production operations.

Original title and link: Distributed System Reliability: It’s About Operations, Not Architecture or Design (NoSQL database©myNoSQL)

via: http://blog.empathybox.com/post/19574936361/getting-real-about-distributed-system-reliability

Being it IT, devops, or no-ops, operations are a critical part of every fairly sized system with real, expressed or not, SLAs. John E. Vincent’s post is an interesting look at what he feels is missing to make system operations more managable:

What I feel like we’re missing is a way to express those relationships and then trigger on them all the way up and down the chain as needed. We’re starting to get into graph territory here.

We must we be able to express and act on changes at the micro level (I changed a config, I must restart nginx) and even at the intranode level (something changed in my app tier, need to tell my load balancer) but now we need a way handle it at that macro level. Not only do we need a way to handle it but we must also be able to calculate what is impacted by that change.

Original title and link: How Can Graphs Apply to IT Operations (NoSQL database©myNoSQL)

via: http://blog.lusis.org/blog/2012/03/06/graphs-in-operations/