[id='performance-partition-handling_{context}']
= Network partitions and degraded clusters

{brandname} clusters can encounter split brain scenarios where subsets of nodes in the cluster become isolated from each other and communication between nodes becomes disjointed.
When this happens, {brandname} caches in minority partitions enter **DEGRADED** mode while caches in majority partitions remain available.

[NOTE]
====
Garbage collection (GC) pauses are the most common cause of network partitions.
When GC pauses result in nodes becoming unresponsive, {brandname} clusters can start operating in a split brain network.

Rather than dealing with network partitions, try to avoid GC pauses by controlling JVM heap usage and by monitoring and tuning the GC. The default G1GC is appropriate for most use cases but needs tuning according to the usage pattern. A different GC implementation, such as Shenandoah, could be beneficial but might not work well if there are many short living objects. For information about the Shenandoah GC, see link:https://docs.redhat.com/en/documentation/red_hat_build_of_openjdk/21/html-single/using_shenandoah_garbage_collector_with_red_hat_build_of_openjdk_21/index#shenandoah-gc-overview[Shenandoah garbage collector]. 
====

.CAP theorem and partition handling strategies

CAP theorem expresses a limitation of distributed, key/value data stores, such as {brandname}.
When network partition events happen, you must choose between consistency or availability while {brandname} heals the partition and resolves any conflicting entries.

Availability:: Allow read and write operations.
Consistency:: Deny read and write operations.

{brandname} can also allow reads only while joining clusters back together.
This strategy is a more balanced option of consistency by denying writes to entries and availability by allowing applications to access (potentially stale) data.

.Removing partitions

As part of the process of joining the cluster back together and returning to normal operations, {brandname} resolves conflicting entries according to a merge policy.

By default {brandname} does not attempt to resolve conflicts on merge which means clusters return to a healthy state sooner and there is no performance penalty beyond normal cluster rebalancing.
However, in this case, data in the cache is much more likely to be inconsistent.

If you configure a merge policy then it takes much longer for {brandname} to heal partitions.
Configuring a merge policy results in {brandname} retrieving every version of an entry from each cache and then resolving any conflicts as follows:

[%autowidth,%noheader,cols="1,1",stripes=even]
|===
|`PREFERRED_ALWAYS`
|{brandname} finds the value that exists on the majority of nodes in the cluster and applies it, which can restore out of date values.

|`PREFERRED_NON_NULL`
|{brandname} applies the first non-null value that it finds on the cluster, which can restore out of date values.

|`REMOVE_ALL`
|{brandname} removes any entries that have conflicting values.
|===
