Handle Topology Change

What is a "topology" change?

Within an Indexima cluster, hyperindexes structures are uniformly spread on multiple nodes.

You may decide to remove one or more nodes because of a maintenance operation for example.

In that case, the remaining nodes of your cluster will split the data that was previously handled by the removed nodes.

That is what we call a "topology" change.

What happens when a "topology" change occurs?

For "READ" operations, this event is transparent.

When you are doing a more impacting operation like adding an index on a table, the following error message will be displayed:

Due to an elasticity event, you must do an INSERT/COMMIT (optionally empty) on table=YOUR_TABLE before adding a new index

You will have to send a COMMIT on that table before adding your index.

If you have many tables, you will have to send a COMMIT to each table.

Apply topology

To avoid sending COMMIT to each table, you can use this operation:

APPLY TOPOLOGY [IN schema_name];

This will:

• returns the list of tables that requires to be committed
• automatically send a COMMIT to each table listed above 

You can also decide to use this operation on a specific schema

Configuration

You can set the following variable in galactica.conf:

topology.change.autocommit = true

The default value of this variable is false.

when the variable is set to true, and a user is adding an index, and Indexima detects a COMMIT that needs to be sent on a table.

• The COMMIT will be automatically sent for this table.
• the addition of the index is put on hold waiting