<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 3, 2017, at 11:54 AM, Heiko W.Rupp <<a href="mailto:hrupp@redhat.com" class="">hrupp@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 3 Mar 2017, at 16:54, Matt Wringe wrote:<br class=""><br class=""><blockquote type="cite" class="">But how do we handle the situations where we want to go from Cassandra <br class="">3.x to Cassandra 4.x? Or what happens when we need to update <br class="">components when those components themselves don't support this type of <br class="">rollback?<br class=""></blockquote><br class="">I did not say this is easy :)<br class=""><br class="">Let me construct a case to illustrate this.<br class=""><br class="">In version N we have a column that stores a string in the form<br class="">"tenantId:metricid". Now we decide for N+1 that this is not<br class="">good and we need to split that in two separate columns.<br class=""><br class="">In a traditional way we would do the split and also remove the<br class="">old single column. Here a rollback is not possible.<br class=""><br class="">If we change this to keep the old column around and the two<br class="">new ones we are safe for version N+1, but as there may be<br class="">still version N containers around we may end up with inconsistencies<br class="">when version N updates an item and N+1 already has split that row.<br class=""><br class="">Here version N+1 would potentially need to read/write from both<br class="">scenarios and also update both (if the old one still exists, see below).<br class="">This allows rolling back.<br class=""><br class="">Version N+2 could then drop the old "tenantId:metricid" column<br class="">and only operate on the split columns.<br class=""><br class="">Heavier updates like C* version 3.x to 4.x can probably really not<br class="">be done without downtime - especially when they require massive<br class="">migrations of Gigabytes of data.<br class="">But still in this case the Metrics frontend code could work against<br class="">both versions of C* and redundantly store data in both while slowly<br class="">migrating data over. Reads could then still go to the old code by<br class="">default until the migration is complete.<br class="">_______________________________________________<br class="">hawkular-dev mailing list<br class=""><a href="mailto:hawkular-dev@lists.jboss.org" class="">hawkular-dev@lists.jboss.org</a><br class=""><a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" class="">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br class=""></div></div></blockquote><br class=""></div><div>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.</div><br class=""></body></html>