Read Repair | Ignite Documentation

Ignite Summit 2023 — Watch on demand — Register now!


Read Repair

Experimental API


A consistency check is incompatible with the following cache configurations:

  • Caches without backups.

  • Near caches.

  • Caches that use "read-through" mode.

Read Repair refers to a technique of repairing inconsistencies between primary and backup copies of data during normal read operations. When a specific key (or keys) is read by a user operation, Ignite checks the values for the given key in all backup copies.

The Read Repair mode is designed to maintain consistency. However, read operations become ~2 times more costly because backup copies are checked in addition to the primary copy. It is generally not advisable to use this mode all the time, but rather on a once-in-a-while basis.

To enable the Read Repair mode, it is necessary to obtain an instance of the cache that enables Read Repair reads as follows:

IgniteCache<Object, Object> cache =

Object value = cache.get(42);


In case consistency violations were found, the values across the topology will be replaced by repaired values according to the chosen strategy:

Strategy Description


Last write (the newest entry) wins.

May cause IgniteException when the fix is impossible (unable to detect the newest entry)
  • Null(s) found as well as non-null values for the same key. Null (missed entry) has no version, so, it can not be compared with the versioned entry.

  • Entries with the same version have different values.


Value from the primary node wins.


The relative majority, any value found more times than any other wins. Works for an even number of copies (which is typical of Ignite) instead of an absolute majority.

May cause IgniteException when it is unable to detect values found more times than any other.

For example, when 5 copies (4 backups) are given
  • and value A found twice, but X, Y and Z only once, A wins,

  • but, when A is found twice, as well as B, and X only once, the strategy is unable to determine the winner.

When 4 copies (3 backups) are given, any value found two or more times, when others are found only once, is the winner.


Inconsistent entries will be removed.


Only check will be performed.


Сonsistency Violation Event will be recorded for each violation in case it’s configured as recordable. You may listen to this event to get notified about inconsistency issues.

Please, refer to the Working with Events section for the information on how to listen to events.

Transactional Caches

Values will be repaired
  • automatically for transactions that have TransactionConcurrency.OPTIMISTIC concurrency mode or TransactionIsolation.READ_COMMITTED isolation level,

  • at commit() phase for transactions that have TransactionConcurrency.PESSIMISTIC concurrency mode and isolation level other than TransactionIsolation.READ_COMMITTED



This proxy usage does not guarantee "all copies check" in case the value have been already cached inside the transaction.

In case you don’t use a READ_COMMITTED isolation mode and already have a cached value, for example have already read the value or performed a write, you’ll just get the cached value.

Atomic Caches

Values will be repaired automatically.



Due to the nature of an atomic cache, false-positive results can be observed. For example, an attempt to check consistency under cache’s loading may lead to a consistency violation exception.

By default, the implementation tries to check the given key three times. The number of attempts can be changed using IgniteSystemProperties.IGNITE_NEAR_GET_MAX_REMAPS property.