Data Redistribution

Data redistribution is done in the background and does not block ongoing operations while data is being transferred.

When the sending copyset completes its migration of data, it briefly delays live operations while assigning ownership to the new copyset. During this interval, transactions that were started during the migration process might fail, and iterator creation and query execution might fail. After this, there is a period of time where other processes (nodes and proxies) in the data grid begin to learn about the change in ownership of the data now at the new copyset so it is expected that operations occurring during that window could experience a timeout error at the client while the processes learn about the new configuration.

Statements and table listeners created prior to the data redistribution are out of date once the data redistribution is completed and receives an invalid resource error at the client. The object must be destroyed in the client application and re-created.

An existing copyset that sends data to a new copyset retains its data on disk until the data redistribution process is complete. The rows previously owned by the copyset are deleted as a background operation.
Note: For capacity planning purposes, it is possible that the portion of data being contributed by a copyset at the moment the redistribution is completed exists at both the old copyset and new copyset. In other words, in a one to two copyset redistribution scenario where the one existing copyset contains 100GB of data and is contributing 50GB to a new copyset, there would be a time where the total aggregate disk usage would be 150GB (this does not account for any additional disk usage by background activities like compaction).