// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
= Data Rebalancing

== Overview

When a new node joins the cluster, some of the partitions are relocated to the new node so that the data remains distributed equally in the cluster. This process is called _data rebalancing_.

If an existing node permanently leaves the cluster and backups are not configured, you lose the partitions stored on this node.
When backups are configured, one of the backup copies of the lost partitions becomes a primary partition and the rebalancing process is initiated.

[CAUTION]
====
Data rebalancing is triggered by changes in the link:clustering/baseline-topology[Baseline Topology].
In pure in-memory clusters, the default behavior is to start rebalancing immediately when a node leaves or joins the cluster (the baseline topology changes automatically).
In clusters with persistence, the baseline topology has to be changed manually (default behavior), or can be changed automatically when link:clustering/baseline-topology#baseline-topology-autoadjustment[automatic baseline adjustment] is enabled.
====

Rebalancing is configured per cache.

== Configuring Rebalancing Mode

Ignite supports both synchronous and asynchronous rebalancing.
In the synchronous mode, any operation on the cache data is blocked until rebalancing is finished.
In the asynchronous mode, the rebalancing process is done asynchronously.
You can also disable rebalancing for a particular cache.

To change the rebalancing mode, set one of the following values in the cache configuration.

- `SYNC` — Synchronous rebalancing mode. In this mode, any call to the cache public API is blocked until rebalancing is finished.
- `ASYNC` — Asynchronous rebalancing mode. Distributed caches are available immediately and load all necessary data from other available cluster nodes in the background.
- `NONE` — In this mode no rebalancing takes place, which means that caches are either loaded on demand from the persistent storage whenever data is accessed, or populated explicitly.

:javaFile: {javaCodeDir}/RebalancingConfiguration.java
:xmlFile: code-snippets/xml/rebalancing-config.xml

[tabs]
--
tab:XML[]
[source,xml]
----
include::{xmlFile}[tags=!*;ignite-config;mode,indent=0]
----
tab:Java[]
[source,java]
----
include::{javaFile}[tags=!*;ignite-config;mode,indent=0]
----
tab:C#/.NET[]
[source,csharp]
----
include::code-snippets/dotnet/DataRebalancing.cs[tag=RebalanceMode,indent=0]
----
tab:C++[unsupported]
--

== Configuring Rebalance Thread Pool

By default, rebalancing is performed in one thread on each node.
It means that at each point in time only one thread is used to transfer batches from one node to another, or to process batches coming from the remote node.
////
For example, if the cluster has two nodes and a single cache, all the cache's partitions will be re-balanced sequentially, one by one.
If the cluster has two nodes and two caches, then the caches will be re-balanced in-parallel *TODO*
////

You can increase the number of threads that are taken from the system thread pool and used for rebalancing.
A system thread is taken from the pool every time a node needs to send a batch of data to a remote node or needs to process a batch that came from a remote node.
The thread is relinquished after the batch is processed.

[tabs]
--
tab:XML[]
[source,xml]
----
include::{xmlFile}[tags=!*;ignite-config;pool-size,indent=0]
----
tab:Java[]
[source,java]
----
include::{javaFile}[tags=!*;ignite-config;pool-size,indent=0]
----
tab:C#/.NET[unsupported]
tab:C++[unsupported]
--


CAUTION: System thread pool is widely used internally by all the cache related operations (put, get, etc.), SQL engine, and other modules. Setting the size of the rebalancing thread pool to a large value may significantly increase rebalancing performance at the cost of decreased throughput.


== Rebalance Message Throttling [[throttling]]

When data is transferred from one node to another, the whole data set is split into batches and each batch is sent in a separate message.
You can configure the batch size and the amount of time the node waits between messages.


[tabs]
--
tab:XML[]
[source,xml]
----
include::{xmlFile}[tags=!*;ignite-config;throttling,indent=0]
----
tab:Java[]
[source,java]
----
include::{javaFile}[tags=!*;ignite-config;throttling,indent=0]
----
tab:C#/.NET[]
[source,csharp]
----
include::code-snippets/dotnet/DataRebalancing.cs[tag=RebalanceThrottle,indent=0]
----
tab:C++[unsupported]
--

== Other Properties

The following table lists the properties of `CacheConfiguration` related to rebalancing:

[CAUTION]
====
`rebalanceDelay` and related API's are deprecated and will be removed in the next releases.
====

[cols="1,4,1",opts="header"]
|===
| Property | Description  | Default Value
| `rebalanceDelay` | A delay in milliseconds before the rebalancing process starts after a node joins or leaves the topology. Rebalancing delay is useful if you plan to restart nodes or start multiple nodes at once or one after another and don't want to repartition and rebalance the data until all nodes are started.
|0 (no delay)

|`rebalanceBatchSize` | The size in bytes of a single rebalance message. The rebalancing algorithm splits the data on every node into multiple batches prior to sending it to other nodes. | 512KB

|`rebalanceThrottle`  | See <<#throttling>>.| 0 (throttling disabled)

| `rebalanceOrder` | The order in which rebalancing should be done. Rebalance order can be set to a non-zero value for caches with SYNC or ASYNC rebalance modes only. Rebalancing for caches with smaller rebalance order is completed first. By default, rebalancing is not ordered. | 0

|`rebalanceTimeout` | Timeout for pending rebalancing messages when they are exchanged between the nodes. | 10 seconds
|===


== Monitoring Rebalancing Process

You can monitor the link:monitoring-metrics/metrics#monitoring-rebalancing[rebalancing process for specific caches using JMX].