Upgrading the Ignite cluster while keeping the system functional

[evariste galois <ev...@yahoo.com>]

Hello,

We are going to run a distributed system containing java applications using Apache Ignite. JDBC interface is used for storing data using SQL and regular clients use distributed caches and dispatch of ordered messages. 
What would be options to keep the system up and functioning while upgrading the underlying Apache Ignite cluster referred to as A?
An exploratory solution is to spin up a new Apache Ignite cluster instance (B), copy the data from A to B, switch connections on all clients and upgrade A to the new version.Once the new cluster is up, apply the delta modifications and switch client connections from B to A. This already sounds too complicated to be feasible.
What options would be have? Write-behind to keep B in relative sync with A? Other?
Any thoughts are appreciated.

Thank you,Marian

Re: Upgrading the Ignite cluster while keeping the system functional

[Ilya Kasnacheev <il...@gmail.com>]

Hello!

Unfortunately Apache Ignite has neither rolling version upgrades nor
replication of data between clusters. So you should expect to see downtime.
However, this is only for version upgrades, you can usually upgrade your
own code with rolling restarts (make sure rebalance is done after each one).

We consider having Rolling Upgrades somewhere in the future.

There is a commercial implementation of these features on a codebase based
off Apache Ignite, though.

Regards,
-- 
Ilya Kasnacheev


ср, 27 нояб. 2019 г. в 14:28, evariste galois <evariste_galois_77@yahoo.com
>:

> Hello,
>
>
> We are going to run a distributed system containing java applications
> using Apache Ignite. JDBC interface is used for storing data using SQL and
> regular clients use distributed caches and dispatch of ordered messages.
>
> What would be options to keep the system up and functioning while
> upgrading the underlying Apache Ignite cluster referred to as A?
>
> An exploratory solution is to spin up a new Apache Ignite cluster instance
> (B), copy the data from A to B, switch connections on all clients and
> upgrade A to the new version.
> Once the new cluster is up, apply the delta modifications and switch
> client connections from B to A. This already sounds too complicated to be
> feasible.
>
> What options would be have? Write-behind to keep B in relative sync with
> A? Other?
>
> Any thoughts are appreciated.
>
>
> Thank you,
> Marian
>
>
>