Режим Read Repair#

Внимание

Это экспериментальный API.

Ограничения

Проверка согласованности несовместима со следующими конфигурациями кеша:

кеши без резервных копий;
near-кеши — подробнее о них написано в подразделе «Near-кеши» раздела «Настройка кешей;
кеши, которые используют режим сквозного чтения (read-through).

Режим Read Repair — метод устранения несоответствий между основными (primary) и резервными (backup) копиями данных во время обычных операций чтения. Когда пользовательская операция считывает конкретный ключ (или ключи), DataGrid проверяет его значения во всех резервных копиях.

Режим Read Repair создан для поддержания согласованности данных. В этом режиме операции чтения становятся примерно в два раза дороже (по времени и нагрузке на CPU), так как помимо основных копий данных проверяются и резервные. Обычно этот режим не рекомендуется использовать на постоянной основе, его стоит включать при необходимости.

Чтобы включить режим Read Repair, получите экземпляр кеша, который включает чтение Read Repair:

IgniteCache<Object, Object> cache =
    ignite.cache("my_cache").withReadRepair(ReadRepairStrategy.CHECK_ONLY);

Object value = cache.get(42);

Стратегии#

Если обнаружились нарушения согласованности данных, по всей топологии значения заменятся на восстановленные согласно выбранной стратегии:

Стратегия	Описание
`LWW`	Выбирается последнее записанное значение (последняя запись) — Last Write Wins. Если исправить нарушения согласованности невозможно (то есть не получается найти последнее записанное значение), может сгенерироваться исключение `IgniteException`. Возможные причины: Найдены `null`- и ненулевые значения для одного ключа. У `null` (пропущенной записи) нет версии, поэтому ее нельзя сравнить с версионированной записью. У записей c одинаковой версией разные значения
`PRIMARY`	Выбираются значения c основного узла
`RELATIVE_MAJORITY`	Выбирается любое значение, которое нашли больше раз, чем остальные. Работает для четного количества копий, которое характерно для DataGrid, вместо абсолютного большинства. Если не получается обнаружить значения, которые нашли больше раз, чем остальные, может сгенерироваться исключение `IgniteException`. Например, есть 5 копий (4 резервные копии): если значение `A` нашлось дважды, а `X`, `Y` и `Z` — один раз, выбирается `A`; если значения `A` и `B` нашлись дважды, а `X` — только один раз, стратегия не сможет выбрать значение. При наличии 4 копий (3 резервных копий) выбирается любое значение, которе нашлось два и более раз (если остальные значения нашлись только один раз)
`REMOVE`	Несогласованные записи удалятся
`CHECK_ONLY`	Выполнится только проверка

События#

Событие нарушения согласованности регистрируется для каждого нарушения (если в настройке указано, что оно записываемое). Чтобы получать уведомления о проблемах несогласованности данных, настройте слушатели событий — подробнее о них написано в разделе «Работа с событиями».

Транзакционные кеши#

Значения будут исправлены автоматически:

для транзакций с режимом параллелизма TransactionConcurrency.OPTIMISTIC или уровнем изоляции TransactionIsolation.READ_COMMITTED;
на фазе commit() — для транзакций с режимом параллелизма TransactionConcurrency.PESSIMISTIC и уровнем изоляции, отличным от TransactionIsolation.READ_COMMITTED.

Ограничения

Использование этого прокси не гарантирует проверку всех копий в случае, если значение уже кешировано внутри транзакции.

Если не используется режим изоляции READ_COMMITTED и есть кешированное значение (например, уже прочитали значение или выполнили запись), можно получить только кешированное значение.

Атомарные кеши#

Значения будут исправлены автоматически.

Ограничения

Из-за особенностей атомарного кеша можно получить ложноположительные результаты. Например, при попытке проверить согласованность во время загрузки кешей можно получить нарушения согласованности данных.

По умолчанию реализация трижды пытается проверить заданный ключ. Количество попыток можно изменить с помощью свойства IgniteSystemProperties.IGNITE_NEAR_GET_MAX_REMAPS.