Data Redistribution

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

When the sending copyset completes its migration of data, it will briefly delay live operations while assigning ownership to the new copyset. During this interval, transactions that were started during the migration process may fail, and iterator creation and query execution may 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 will be out of date once the data redistribution is completed and will receive an invalid resource error at the client. The object should be destroyed in the client application and recreated.

An existing copyset that sends data to a new copyset will retain 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).