Восстановление согласованности партиций с помощью cli-утилит#

Предусловия#

Установленный продукт DataGrid. Подробнее об установке продукта написано в документе «Руководство по установке».

Введение#

DataGrid предоставляет гарантии согласованности данных, означающие, что все копии партиций будут содержать одни и те же значения для каждого из ключей.

Однако по различным причинам эти гарантии могут быть нарушены. Такими причинами могут быть:

• дефекты;

• сбои;

• неидемпотентные операции над данными, выполняемые более одного раза.

Для восстановления согласованности данных существует cli-утилита, использующая специальный режим чтения из всех копий партиции и проверяющая, что значения в них одинаковы. Если значения в основной и резервной партициях отличаются, утилита исправит это при помощи одной из стратегий восстановления согласованности. Стратегии описываются далее в разделе «Стратегии проверки и восстановления согласованности данных».

Стратегии проверки и восстановления согласованности данных#

Существует пять стратегий проверки и восстановления согласованности данных:

• LWW — Last Write Wins — побеждает последняя (самая новая) запись:

  Использование данной стратегии может приводить к исключению IgniteException в случае, если восстановление согласованности данных невозможно (невозможно определить самую новую запись). Это происходит в следующих случаях:

  • для одного и того же ключа найдены значения null и отличное от null. У пропущенной записи (null) нет версии и сравнить ее с версионированной записью невозможно;

  • записи одной версии имеют различные значения.

• PRIMARY — Value from the primary node wins — побеждает значение, полученное с основной копии партиции;

• RELATIVE_MAJORITY — Relative majority wins — побеждает относительное большинство (самое часто встречающееся значение):

  Внимание

  Данная стратегия, в отличие от стратегии с «абсолютным большинством», работает для четного числа копий. Использование данной стратегии может приводить к исключению IgniteException, если определить самое часто встречающееся значение не представляется возможным.

  • Например, даны 5 копий партиции (из них 1 копия — основная, 4 копии — резервные):

    • Если значение A встречается 2 раза, а значения X, Y и Z — по 1 разу, то в результате побеждает значение A.

    • Если значения A и B встречаются по 2 раза, а значение X — 1 раз, то такая стратегия не сможет определить победителя.

  • Если даны 4 копии партиции (из них 1 копия — основная, 3 копии — резервные), то любое значение, найденное два или более раз, когда другие найдены только один раз, является победителем.

• REMOVE — Inconsistent values will be removed — несогласованные значения будут удалены. Это означает потерю несогласованных данных;

• CHECK_ONLY — Only check will be performed — будет проведена только проверка согласованности.

Проверка и восстановление согласованности с помощью утилиты control#

Проверка и восстановление согласованности осуществляются с помощью утилиты control, которая включает в себя набор команд. Описание команд приведено в разделе «Проверка и восстановление данных».

Пример целевого использования механизма#

<property name="includeEventTypes">
            <list>
                <util:constant static-field="org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION"/>
            </list>
        </property>

Подход к целевому использованию механизма восстановления согласованности включает в себя использование утилиты idle_verify для проверки согласованности данных. Такой подход позволяет избежать излишнего перемещения данных по сети. Вместо этого по сети перемещается лишь вычисленный локальный хеш, что повышает производительность работы механизма.

Алгоритм работы механизма при таком подходе:

1. Утилита idle_verify проверяет согласованность данных на кластере без нагрузки (иначе есть риск ложного срабатывания).

2. Утилита idle_verify предоставляет информацию о наличии несогласованности.

3. Каждое расхождение логируется при помощи стратегии CHECK_ONLY.

4. log-файл (например, consistency.log) анализируется администратором.

   Примечание

   По умолчанию запись происходит в общий лог DataGrid. Однако можно сконфигурировать запись в любой другой файл по усмотрению пользователя. Для этого измените путь к файлу на желаемый в конфигурации logger (переменная filename), например:

   XML#

   <File name="CONSISTENCY" fileName="${sys:IGNITE_HOME}/work/log/consistency.log">
       <PatternLayout>
           <Pattern>"[%d{ISO8601}][%-5p][%t][%c{1}] %m%n"</Pattern>
               </PatternLayout>
     </File>
   

5. Для устранения случаев несогласованности используются стратегии LWW, PRIMARY, RELATIVE_MAJORITY, REMOVE.

Для реализации подхода:

1. Запустите утилиту idle_verify на проверку согласованности данных с необходимыми вам аргументами:

   control.sh --cache idle_verify --host localhost --user user --password ***** --keystore /path/to/keystore.jks --keystore-password ***** --truststore /path/to/truststore.jks --truststore-password *****
   

2. Утилита idle_verify обнаруживает несогласованность:

   idle_verify check has finished, found 2 conflict partitions.
   
   Conflict partition: PartitionKey [grpId=xxxxxxxxxx, grpName=default, partId=x]
   Partition instances: [PartitionHashRecord [isPrimary=true, partHash=xxxxxxxxxx, updateCntr=3, size=3, consistentId=xxxxxxxx], PartitionHashRecord [isPrimary=false, partHash=xxxxxxxxxx, updateCntr=3, size=2, consistentId=xxxxxxxx]]
   Conflict partition: PartitionKey [grpId=xxxxxxxxxx, grpName=default, partId=x]
   Partition instances: [PartitionHashRecord [isPrimary=true, partHash=xxxxxxxxxx, updateCntr=3, size=3, consistentId=xxxxxxxx], PartitionHashRecord [isPrimary=false, partHash=xxxxxxxxxx, updateCntr=3, size=2, consistentId=xxxxxxxx]]
   

3. Запустите проверку согласованности при помощи стратегии CHECK_ONLY для оценки расхождений; подробнее о проверки согласованности с помощью control.sh смотрите в разделе «Восстановление согласованности кешей».

4. Просмотрите log-файл, оцените его и примите решение относительно выбора стратегии восстановления согласованности.

5. Запустите команду repair для запуска механизма Read repair на устранение расхождений, используя одну из описанных выше стратегий; подробнее о выполнении команды с помощью control.sh смотрите в разделе «Восстановление согласованности кешей».