That's right, most/always no down-time requirement is managed by having replicated cluster setups (Disaster-recovery/backup site). The data is either pushed to both systems through the data ingesters or by using WAN setup. The clusters are upgraded one at a time. If there is a failure during upgrade or needs to be rolled back; one system will be always up and running.
-Anil. On Wed, Apr 22, 2020 at 1:51 PM Anthony Baker <aba...@pivotal.io> wrote: > Anil, let me see if I understand your perspective by stating it this way: > > If cases where 100% uptime is a requirement, users are almost always > running a disaster recovery site. It could be active/active or > active/standby but there are already at least 2 clusters with current > copies of the data. If an upgrade goes badly, the clusters can be > downgraded one at a time without loss of availability. This is because we > ensure compatibility across the wan protocol. > > Is that correct? > > > Anthony > > > > > On Apr 22, 2020, at 10:43 AM, Anilkumar Gingade <aging...@pivotal.io> > wrote: > > > >>> Rolling downgrade is a pretty important requirement for our customers > >>> I'd love to hear what others think about whether this feature is worth > > the overhead of making sure downgrades can always work. > > > > I/We haven't seen users/customers requesting rolling downgrade as a > > critical requirement for them; most of the time they had both an old and > > new setup to upgrade or switch back to an older setup. > > Considering the amount of work involved, and code complexity it brings > in; > > while there are ways to downgrade, it is hard to justify supporting this > > feature. > > > > -Anil. > >
