• Created by Unknown User (nizhikov) on Nov 08, 2024 2 minute read

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Motivation

For now, Ignite cluster can be updated only by full cluster restart.

Procedure must be the following:

  1. stop all cluster nodes.
  2. update files on each node.
  3. start nodes one by one.

So, each version update is a cluster temporary unavailability.

This is extremely inconvenient for the user, especially one who use Ignite as a primary data storage.

We must add rolling upgrade feature to the Ignite.

Description

Rolling Upgrade assume that cluster can consist of Ignite versions of different versions.
So Ignite must provide backward compatibility on network level and ability to work in mixed topology.
Development time checks, tests must be added to provide protection of incorrect patches.
Ignite codebase must be reorganized in a way to clearly distinguish those parts that require compatibility and those who don't.

Let's define clearly, what "backward compatibility" for the network messages means:

  • New Ignite server MUST be able to read previous version of message.
  • Old Ignite server MUST be able to read new version of message
    • Newly added fields MUST be ignored.
    • Removed fields MUST have default values. 

Let's list subsystems that must be reworked to provide compatibility:

  • communication: Communication messages consists of two parts:
    • Message format: message format itself. Communication API should be reworked to force backward compatible messages.
    • User data: Message can store user data. User data format must be backward compatible.
  • discovery:
    • Message format: message format itself. Communication API must be reworked to force backward compatible messages.
  • binary marshaller:
    • Currently, binary marshaller code highly coupled with the other Ignite code. We must modularize Binary infrastructure (IEP-119 Binary infrastructure modularization) and provide compatibility guarantees for each part of it.
  • features:
    • Framework to enable/disable features for mixed version clusters must be developed.

Additional materials

Many distributed open source systems has rolling upgrade feature, already.
We must study implemented approaches to gain some insights from them.

  • Apache Cassandra.
  • Apache Kafka.
  • Yugabyte
  • Cockroach DB.
     
  • No labels

Apache Ignite