1

I have a Ignite cluster of 2 or more nodes (max of 4) in server mode.

Let's say I have an Ignite cache defined by Java class called Employee (let's say this is version 1) loaded and used. If I update this Employee class with a new member field (version 2), how would I go about updating the loaded class with the new version (ie update the cache definition)? How does Ignite handle objects (cache records) created previously based on Employee version 1 vs new cache records created with Employee version 2? If I have SQL queries using new fields as defined in version 2, is that going to fail because the Employee version 1 based objects/cache records are not compatible with new SQL using the newly defined field(s) in Employee version 2?

I can delete db folder from the working directory, reload the new class as part of restarting the Ignite service. But, I lose all previous data.

Cluster member with updated Employee class definition will not join other nodes in the cluster still loaded with original Employee version 1 class. Again, I need to shutdown all members in the cluster and reload the new Employee version and restart all members in the cluster.

Chris
  • 11
  • 2

1 Answers1

1

Ignite doesn't store code versions. The latest deployed class is in use.

in order to preserve the fields, Ignite builds binary meta for a customer type and stores it for validation. If you are going to add new fields and leave the old ones untouched, Ignite will update the meta automatically, nothing to configure/change. A old record will be deserialised with new fields set to null.

For SQL it's recommended to go with DDL to adjust the schema accordingly:

ALTER TABLE "schema".MyTable DROP COLUMN oldColumn
ALTER TABLE "schema".MyTable ADD COLUMN newColumn VARCHAR;

You can check available meta using control script --meta command (not sure if it's available in Ignite edition though)

control.sh --meta list

Ignite won't propagate POJO changes automatically using peerClassLoading. You should either update the JARs manually or rely on some deployment SPI, like URL deployment.

Overall, you should not remove your db folder each time you are going to make changes to your POJOs/SQL tables. Adding new fields should be totally OK. Do not remove the old fields, it's better to mark them as deprecated.

Alexandr Shapkin
  • 2,350
  • 1
  • 6
  • 10
  • Thank you for the response. I was able to successfully apply the recommendation on members of existing cluster. However, this is not sufficient if a brand new member is to join the cluster of upgraded members. For example, if I have a cluster of member1 and member2, and I upgrade both members with updated class (ie. Employee class version 2), everything works. But, if I setup a fresh Ignite DB instance (on a separate machine) with updated Employee class and try to have the new Ignite instance join the existing cluster of 2, it fails with an Exception – Chris Apr 26 '23 at 20:16
  • The Exception detail includes:: Caused by: org.apache.ignite.spi.IgniteSpiException: Failed to join node to the active cluster (the config of the cache 'EmpoyeeCache' has to be merged which is impossible on active grid). Deactivate grid and retry node join or clean the joining node. I am assuming I have to shutdown all Ignite instance and start them again? There is no in-service joining existing cluster? – Chris Apr 26 '23 at 20:17