Strategy for upgrading to a binary-incompatible version of Ignite

Question

I am evaluating Apache Ignite data grid for the production usage.

One of critical requirements is to have a well defined stragegy for upgrading a large system to a binary incompatible version (usually unavoidable when using binary protocols like Ignite does). More specifically, upgrading the Ignite infrastructure independently (before or after) from the large number of Ignite client node components and/or Ignite thin clients.

So wondering what would such process look like, for situation when upgrading all the components of the system as a big-bang is not practically possible.

Answer 1

If your primary objective is clients which should access cluster without downtime during upgrade, I can recommend that most of those clients should be 'thin' clients, such as JDBC client, ODBC client, REST or Java/C#/C++/node.js thin clients which are under active development currently. They have no strict version checking.

So you should avoid using 'thick' clients (a.k.a. Apache Ignite client nodes) and only for operations which can't be performed by thin clients. Or use Rolling Upgrades as mentioned.

Answer 2

First, Ignite cares about the compatibility of its binary format and doesn’t change it without some fallback mechanisms. In particular, backward compatibility of the persistent storage (ability to upgrade and continue to use the same DB files) is preserved.

Second, to upgrade a production cluster there is a Rolling Upgrade feature offered by GridGain (built on top of Ignite). See this for details: https://docs.gridgain.com/docs/rolling-upgrades.