Re: [Hawkular-dev] Rolling upgrades (on Kubernetes)

From: "John Sanda" <jsanda(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Friday, 3 March, 2017 2:18:39 PM Subject: Re: [Hawkular-dev] Rolling upgrades (on Kubernetes) On Mar 3, 2017, at 11:54 AM, Heiko W.Rupp < hrupp(a)redhat.com > wrote: On 3 Mar 2017, at 16:54, Matt Wringe wrote: But how do we handle the situations where we want to go from Cassandra 3.x to Cassandra 4.x? Or what happens when we need to update components when those components themselves don't support this type of rollback? I did not say this is easy :) Let me construct a case to illustrate this. In version N we have a column that stores a string in the form "tenantId:metricid". Now we decide for N+1 that this is not good and we need to split that in two separate columns. In a traditional way we would do the split and also remove the old single column. Here a rollback is not possible. If we change this to keep the old column around and the two new ones we are safe for version N+1, but as there may be still version N containers around we may end up with inconsistencies when version N updates an item and N+1 already has split that row. Here version N+1 would potentially need to read/write from both scenarios and also update both (if the old one still exists, see below). This allows rolling back. Version N+2 could then drop the old "tenantId:metricid" column and only operate on the split columns. Heavier updates like C* version 3.x to 4.x can probably really not be done without downtime - especially when they require massive migrations of Gigabytes of data. But still in this case the Metrics frontend code could work against both versions of C* and redundantly store data in both while slowly migrating data over. Reads could then still go to the old code by default until the migration is complete. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev As far as I know rolling upgrades of Cassandra with a major version change is well supported, and rolling upgrades is pretty common among Cassandra users. Here is the scenario I am not sure we could handle without downtime. We want to make make a schema change that involves something introduced in the new version of Cassandra, e.g., SASI index.

_______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev