[Hawkular-dev] Rolling upgrades (on Kubernetes)

[John Sanda]

> On Mar 3, 2017, at 11:54 AM, Heiko W.Rupp <hrupp at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170303/81af25ce/attachment.html