Резервное копирование и восстановление в DataGrid#

Ограничения процедуры создания резервной копии (снепшота)#

Процедура создания резервной копии (снепшота) имеет ряд ограничений:

• сделать снепшот конкретных кешей и таблиц невозможно. При создании резервной копии всегда создается только полный снепшот;

• в снепшот не включаются кеши и таблицы, не сохраненные в постоянном хранилище Ignite Persistence;

• в процессе создания снепшота нельзя изменять основной ключ. Все кеши снепшота зашифрованы с помощью одного и того же главного ключа;

• операция по созданию снепшота запрещена во время изменения основного ключа и/или изменения ключей группы кешей;

• одновременный запуск нескольких операций создания снепшота невозможен. При попытке запуска нескольких операций параллельно DataGrid выдаст следующую ошибку:

  Cluster-wide snapshot operation failed:
  class org.apache.ignite.IgniteException: Create snapshot request has been rejected. The previous snapshot operation was not completed.
  

• в случае выхода кластера из обслуживания процедура создания резервной копии прерывается;

• сохранение параллельных обновлений DataStreamer с настройкой по умолчанию allowOverwrite (false) в persistence-кеш может привести к тому, что данные кеша сохранятся непоследовательно;

• во время снятия снепшота остановить работу кеша невозможно. При попытке остановки кеша DataGrid выдаст следующее исключение:

  avax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: Operation rejected due to the snapshot operation in progress.
  

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

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

Ограничения для инкрементальных снепшотов#

Процедура создания инкрементальных снепшотов также имеет ряд ограничений. Инкрементальные снепшоты НЕ МОГУТ быть созданы в следующих случаях:

• в кластере представлены зашифрованные кеши;

• кеши были изменены, созданы или удалены с момента снятия полного снепшота;

• после ребалансировки данных в кластере.

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

Создание резервных копий (снепшотов)#

Благодаря использованию режима Native Persistence DataGrid позволяет создавать резервные копии (полные и инкрементальные кластерные снепшоты). Резервная копия включает в себя согласованную копию всех данных кластера, сохраненных на диске, а также другие файлы, необходимые для процедуры восстановления.

Структура резервной копии схожа со структурой каталога постоянного хранилища Ignite Persistence. На схеме ниже приведен пример такой структуры:

work
└── snapshots
    └── backup_name
        ├── increments
        │        └── 0000000000000001
        └── db
            ├── binary_meta
            │         ├── node1
            │         ├── node2
            │         └── node3
            ├── marshaller
            │         └── classname0
            ├── node1
            │    └── my-sample-cache
            │        ├── cache_data.dat
            │        ├── part-3.bin
            │        ├── part-4.bin
            │        └── part-6.bin
            ├── node2
            │    └── my-sample-cache
            │        ├── cache_data.dat
            │        ├── part-1.bin
            │        ├── part-5.bin
            │        └── part-7.bin
            └── node3
                └── my-sample-cache
                    ├── cache_data.dat
                    ├── part-0.bin
                    └── part-2.bin

Пояснение к схеме

Cluster-wide snapshot operation failed:
class org.apache.ignite.IgniteException: Create snapshot request has been rejected. Snapshot with given name already exists on local node.

Создание инкрементальных снепшотов#

При использовании полных снепшотов маловероятно получить низкую допустимую потерю данных (RPO), например, в диапазоне нескольких минут. Это объясняется тем, что полные снепшоты требуют дополнительных ресурсов для создания и хранения всех партиций.

Для упрощения процесса можно использовать инкрементальные снепшоты. Это позволяет:

• хранить изменения данных, которые произошли с момента создания предыдущего полного или инкрементального снепшота;

• упростить процесс создания снепшота с возможностью одновременной загрузки выполнения.

Существует несколько особенностей использования инкрементальных снепшотов:

• инкрементальные снепшоты основаны на существующем полном снепшоте;

• для инкрементальных снепшотов не допускается уплотнение WAL архива;

• инкрементальные снепшоты необходимо создавать на том же накопителе, на котором хранятся WAL архивы.

Во время процедуры восстановления инкрементального снепшота сначала восстанавливается полный снепшот, и только затем последовательно восстанавливаются все инкрементальные снепшоты.

Создание облегченных снепшотов#

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

Использование облегченных снепшотов позволяет:

• сократить время снятия снепшота;

• избежать перегрузки диска в процессе снятия снепшота;

• сократить место на диске, необходимое для хранения снепшота.

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

Гарантии согласованности снепшотов#

Все снепшоты гарантируют согласованность со всеми операциями, связанными с кластером. К ним относятся изменения в данных Ignite Persistence, индексах, схемах, метаданных бинарного типа, marshaller и изменения в других файлах узлов.

Согласованность снепшотов кластера достигается путем запуска Partition-Map-Exchange (PME). Выполнив эту процедуру, кластер в конечном итоге достигнет той точки во времени, когда все ранее начавшиеся транзакции будут завершены, а новые приостановлены. Как только это произойдет, кластер запустит процесс создания снепшота. Процедура PME гарантирует создание такого снепшота, который включает основную и резервную копии, созданные последовательно друг за другом.

Согласованность между файлами Ignite Persistence и копиями их снепшотов достигается благодаря копированию исходных файлов в каталог назначения с отслеживанием всех параллельных текущих изменений. Это отслеживание может потребовать дополнительного пространства в хранилище Ignite Persistence (до 1х размера хранилища).

Гарантии согласованности инкрементальных снепшотов#

Инкрементальные снепшоты достигают согласованности транзакций за счет другого, неблокирующего, подхода, который основан на алгоритме Consistent Cut. Это позволяет запускать инкрементальные снепшоты одновременно с текущей загрузкой, не влияя на производительность.

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

Проверка согласованности снепшотов#

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

Для этого в DataGrid используются встроенные команды для проверки согласованности снепшота. Команды позволяют:

• проверить внутреннюю согласованность данных;

• вычислить партиции данных хешей и контрольных сумм страниц;

• напечатать результат, если обнаружена проблема.

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

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

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

Команды проверки согласованности рекомендуется выполнять в режиме простоя кластера (без записи данных, без выполнения транзакций и вычислительных задач).

Подробнее о проверке согласованности снепшотов с помощью утилиты control.sh смотрите в разделе «Утилита control».

Системные свойства для настройки снепшота#

В таблице ниже перечислены свойства системы, которые позволяют настраивать снепшоты:

Исполнение команд, относящихся к ограничению скорости снятия снепшота, при использовании DataGrid с настроенным плагином безопасности#

При использовании DataGrid с настроенным плагином безопасности для выполнения команд, относящихся к ограничению скорости снятия снепшота, у пользователя должны быть следующие права на выполнение задач и systemPermissions (указываются в файле igniteconfig/default-security-data.json):

    {
      "name": "TEST_PERM",
      "perms": {
        "cachePermissions": {},
        "dfltAllowAll": false,
        "servicePermissions": {},
        "systemPermissions": [
          "ADMIN_READ_DISTRIBUTED_PROPERTY",
          "ADMIN_WRITE_DISTRIBUTED_PROPERTY"
        ],
        "taskPermissions": {
          "org.apache.ignite.internal.commandline.property.tasks.PropertiesListTask": [
            "TASK_EXECUTE"
          ],
          "org.apache.ignite.internal.commandline.property.tasks.PropertyTask": [
            "TASK_EXECUTE"
          ]
            }
        }
    }

Внесенные изменения действуют сразу на весь кластер и будут применены до момента перезагрузки кластера с очисткой distributed metastorage.

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

Конфигурация каталога хранения резервной копии (снепшота)#

По умолчанию сегмент снепшота сохраняется в рабочем каталоге соответствующего узла DataGrid и использует то же пространство, в котором хранятся данные, индексы, WAL-журнал и другие файлы Native Persistence.

Пример изменения пути хранения снепшотов:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
<!--
    Задает путь к корневому каталогу, в котором будут храниться файлы снепшотов. По умолчанию каталог `snapshots` находится в каталоге `IGNITE_HOME/db`.
-->
<property name="snapshotPath" value="/<ignite_home>/server/snapshotPath"/>
</bean>

IgniteConfiguration cfg = new IgniteConfiguration();

File exSnpDir = U.resolveWorkDirectory(U.defaultWorkDirectory(), "ex_snapshots", true);

cfg.setSnapshotPath(exSnpDir.getAbsolutePath());

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

Создание резервной копии (снепшота)#

Для создания резервных копий в поставку DataGrid входят следующие интерфейсы:

• утилита control.sh(подробнее о создании снепшотов смотрите в разделе «Утилита control»);

• JMX;

• Java API.

При создании снепшота в каталоге $IGNITE_HOME/work/db/.../snp создаются файлы партиций с «грязными» страницами. Каждый такой файл партиции будет иметь расширение .delta.

После успешного завершения операции по созданию снепшота данные файлы будут автоматически применены к созданному снепшоту и удалены.

Отображение начала и окончания процесса создания снепшота в log-файлах DataGrid#

В момент запуска операции создания снепшота в журналах DataGrid появляется следующая запись: [IgniteSnapshotManager] Cluster-wide snapshot operation started [snpName=MySnapshot, grps=[1794698200]], где:

• snpName — имя снепшота;

• grps — список кеш-групп в снепшоте.

Когда операция создания снепшота завершается, в логах появляется следующая запись:

[IgniteSnapshotManager] Cluster-wide snapshot operation finished successfully: SnapshotOperationRequest [rqId=1a24fa7d-4e50-4714-ae68-959892c6d5a3, srcNodeId=b7b71afb-32c5-4730-b0dc-5090920cf4f0, snpName=MySnapshot, grpIds=ArrayList [1794698200], bltNodes=HashSet [b7b71afb-32c5-4730-b0dc-5090920cf4f0], err=null]

Использование интерфейса JMX#

Для проведения операций, связанных с созданием резервных копий через интерфейс JMX, используйте SnapshotMXBean:

Использование Java API#

Создать снепшот также можно и из кода, используя Java API:

    link:{javaCodeDir}/Snapshots.java[]

Восстановление из резервной копии (снепшота)#

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

Автоматическое восстановление из снепшота#

Процедура автоматического восстановления из снепшота позволяет восстановить группы кешей из снепшота на работающем (активном) кластере при помощи Java API или утилиты control.sh.

Ограничения текущей реализации

В настоящий момент процедура создания резервной копии (полного или инкрементального снепшота) имеет ряд ограничений:

• восстановление возможно, только если все части снепшота присутствуют в кластере. Каждый узел ищет локальные данные локального снепшота по сконфигурированному пути снепшота (задается системным свойством snapshotPath в конфигурации кластера), используя в качестве «ключевых слов» имя снепшота и согласованный ID (consistent_id) узла. Пример конфигурации пути (указывается в serverExampleConfig.xml):

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <!-- Задает путь к корневому каталогу, в котором будут храниться файлы снепшотов. По умолчанию каталог `snapshots` находится в каталоге `IGNITE_HOME/db`.-->
        <property name="snapshotPath" value="/<ignite_home>/server/snapshotPath"/>
</bean>

• процедура восстановления может применяться только к группам кешей, созданным пользователем;

• группы кешей, которые нужно восстановить из снепшота, не должны находиться в кластере. Если они находятся в кластере, то их нужно удалить со всех узлов кластера перед началом операции восстановления, используя Java API, либо при помощи следующей команды:

  control.sh --cache destroy
  

• проводить несколько операций восстановления параллельно запрещено. Следующая операция восстановления может быть запущена только после окончания предыдущей операции.

Восстановление кеш-группы из снепшота#

Восстановить отдельную группу кешей из снепшота можно при помощи утилиты control.sh или с помощью кода, используя Java API:

   link:{javaCodeDir}/Snapshots.java[]

Настройка и запуск Playbook для управления процессом восстановления при помощи ansible#

Для запуска playbook предварительно заполните файл hosts, в котором заданы хосты кластера.

hosts
[srv_hosts]
x.x.x.x
y.y.y.y
z.z.z.z
....
n.n.n.n

Для запуска передайте следующие переменные:

Переменные передаются как extravars:

ansible-playbook playbooks/restore_snapshots.yml -i ./hosts -e "run_on=srv_hosts ignite_se_instance_home='/ignite/server/' ignite_se_data_dir='/ignite/server/data' ignite_se_work_dir='/ignite/server/work' ignite_se_snapshot_dir='/ignite/server/work/snapshots' ignite_se_snapshot_name='snapshot_simple_1'"

Ручное восстановление из снепшота#

Структура снепшота аналогична структуре хранилища Native Persistence. Для ручного восстановления нужно восстановить снепшот на том же кластере с тем же узлом consistentId и с той же топологией. В противном случае будет произведена ребалансировка после восстановления. Подробнее — см. раздел «Восстановление кластера из снепшота кластера с другой топологией» текущего документа.

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

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
   <property name="consistentId" value="MyId"/>
</bean>

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

1. Остановите кластер.

2. Замените данные и другие файлы, используя информацию из снепшота.

3. Перезапустите узлы.

Подробная инструкция для ручного восстановления из снепшота:

1. Остановите работу кластера, который нужно восстановить.

2. Удалите все данные из каталога контрольной точки $IGNITE_HOME/work/cp (данные Native Persistence и прочие данные).

3. На каждом узле выполните следующие действия:

   • удалите все файлы, относящиеся к {nodeId} из каталога $IGNITE_HOME/work/db/binary_meta;

   • удалите все файлы, относящиеся к {nodeId} из каталога $IGNITE_HOME/work/db/marshaller;

   • удалите все файлы и подкаталоги, принадлежащие к узлу с {nodeId} в каталоге $IGNITE_HOME/work/db. Очистите каталог db/{nodeId} отдельно, если он отсутствует в каталоге work;

   • скопируйте файлы, относящиеся к узлу с {nodeId}, из снепшота в каталог $IGNITE_HOME/work/. Если каталог db/{nodeId} не находится в каталоге work, скопируйте файлы с данными туда.

4. Перезапустите кластер.

Восстановление кластера из снепшота кластера с другой топологией#

При возникновении ситуации неожиданного выхода кластера из строя (например, при сбоях) может потребоваться его восстановление. Однако топологии кластеров могут отличаться, равно как и топологии снепшотов этих кластеров. Таблица ниже описывает ситуации, когда нужно создать снепшот кластера с количеством узлов N и восстановить кластер с количеством узлов M:

Получение статуса операции восстановления из снепшота#

Получить статус текущей операции снепшота в кластере можно при помощи утилиты control.sh|bat с помощью команды --snapshot status или через JMX (интерфейс SnapshotMXBean).

SnapshotMXBean mxBean = ...;

// Статус операции для текущего снепшота в кластере.
String status = mxBean.status();

Отмена операций создания снепшота и восстановления из снепшота#

Отменить текущую операцию по созданию или восстановлению снепшота можно при помощи утилиты control.sh|bat --snapshot cancel --name <name> | --id <id> или интерфейса JMX.

Для отмены перации можно использовать имя снепшота (name) или идентификатор операции (id).

Идентификатор операции отображается при запуске операции с использованием командной строки. Также его можно запросить с помощью команды status или найти идентификатор в метриках снепшота.

Пример команды для отмены операций для снепшотов через JMX (интерфейс SnapshotMXBean):

SnapshotMXBean mxBean = ...;

// Прервать операцию для снепшота с идентификатором `9ec229f1-e0df-41ff-9434-6f08ba7d05bd`.
mxBean.cancelSnapshotOperation("9ec229f1-e0df-41ff-9434-6f08ba7d05bd");

Сценарии работы со снепшотами#

Снятие снепшотов на неполной топологии#

Для корректного снятия снепшотов должны быть настроены все baseline узлы. Проблема со снятием снепшотов возникает на неполной топологии, когда недоступен один или несколько из baseline узлов.

Настройка снятия снепшотов на неполной топологии не имеет смысла. В случае, если снепшоты со смысловым содержимым отсутствуют (BACKUPS = 0), работает PARTITION_LOSS_POLICY. В случае, если BACKUPS > 0:

• восстановите узел;

• дождитесь ребалансировки;

• снимите снепшот.

Восстановление на неполной топологии снепшота из полной топологии#

Восстановление снепшота на неполной топологии нецелесообразно (см. раздел «Снятие снепшотов на неполной топологии»). Чтобы восстановить снепшот, необходимо настроить все baseline узлы.

Восстановление на новой топологии со снепшота из меньшей топологии#

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

Восстановление со снепшота, снятого после ремонта узла#

После ремонта узла может возникнуть потеря PDS (Persistent Data Store) и снепшота. Чтобы восстановить данные с потерянного снепшота, снятого на полной топологии после ремонта узла:

1. Проверьте, что в конфигурации потерянного узла задан consistentId (даже с потерянным параметром lsf).

2. При вводе узла проверьте, что узел из baseline восстановлен.

3. Восстановите снепшот на полном baseline.

Persistence-хранилище данных (Persistent Data Store)#

Persistence, или Native Persistence — это набор функций, разработанных для обеспечения постоянного хранения данных. Когда данный режим включен, DataGrid постоянно хранит все данные на диске, а необходимые данные загружаются в ОЗУ для их обработки.

Если Native Persistence отключен и внешнее хранилище данных не используется, DataGrid будет работать исключительно как in-memory-хранилище.

Если режим Native Persistence включен, то каждый серверный узел хранит определенный набор данных, включающий в себя только партиции, назначенные на этот узел (включая резервные партиции, если включена функция хранения резервных копий).

Функциональность режима Native Persistence состоит из следующих возможностей:

• хранение партиций данных на диске;

• упреждающая журнализация (журнал WAL);

• создание контрольных точек (Checkpointing);

• использование файла подкачки ОС.

При включенном режиме Native Persistence DataGrid хранит каждую партицию в отдельном файле на диске. Формат данных в файлах партиций соответствует формату данных в ОЗУ. При включенной функции хранения резервных копий на диске также сохраняются резервные партиции. Помимо самих партиций с данными DataGrid также хранит индексы и метаданные.

Каталог хранения файлов можно изменить в файле.

Включение Persistence-хранилища данных#

Native Persistence конфигурируется отдельно для каждого региона данных.

Чтобы включить Persistence-хранилище данных, установите значение true для свойства persistenceEnabled в файле конфигурации региона данных.

Пример ниже показывает, как можно включить Persistence-хранилище для стандартного региона данных (указывается в serverExampleConfig.xml):

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="dataStorageConfiguration">
        <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
            <property name="defaultDataRegionConfiguration">
                <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                    <property name="persistenceEnabled" value="true"/>
                </bean>
            </property>
        </bean>
    </property>
</bean>

IgniteConfiguration cfg = new IgniteConfiguration();

// Конфигурация хранилища данных.
DataStorageConfiguration storageCfg = new DataStorageConfiguration();

storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);

cfg.setDataStorageConfiguration(storageCfg);

Ignite ignite = Ignition.start(cfg);

var cfg = new IgniteConfiguration
{
    DataStorageConfiguration = new DataStorageConfiguration
    {
        DefaultDataRegionConfiguration = new DataRegionConfiguration
        {
            Name = "Default_Region",
            PersistenceEnabled = true
        }
    }
};

Ignition.Start(cfg);

Конфигурация каталога Persistence-хранилища данных#

При включенном Native Persistence узел сохраняет данные пользователей, индексы и WAL-файлы в каталоге {IGNITE_WORK_DIR}/db. Данный каталог считается каталогом хранилища. Его можно изменить, установив свойство storagePath объекта DataStorageConfiguration, как показано ниже.

Каждый узел обслуживает следующие подкаталоги хранилища, в котором будут храниться кешированные данные, WAL-файлы, а также файлы архива WAL:

nodeId здесь — это либо согласованный ID узла (consistent node ID), если он определен конфигурацией узла, либо автоматически сгенерированный ID узла. Он используется для обеспечения уникальности каталогов для узла.

Если рабочий каталог содержит файлы persistence-хранения для нескольких узлов (т. е. существует несколько подкаталогов {nodeId} с разными ID узлов), то узел выбирает первый неиспользуемый подкаталог.

Каталог можно изменить следующим образом (указывается в serverExampleConfig.xml):

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="dataStorageConfiguration">
        <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
            <property name="defaultDataRegionConfiguration">
                <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                    <property name="persistenceEnabled" value="true"/>
                </bean>
            </property>
            <property name="storagePath" value="/opt/storage"/>
        </bean>
    </property>
</bean>

IgniteConfiguration cfg = new IgniteConfiguration();

// Конфигурация хранилища данных.
DataStorageConfiguration storageCfg = new DataStorageConfiguration();

storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);

storageCfg.setStoragePath("/opt/storage");

cfg.setDataStorageConfiguration(storageCfg);

Ignite ignite = Ignition.start(cfg);

var cfg = new IgniteConfiguration
{
    DataStorageConfiguration = new DataStorageConfiguration
    {
        StoragePath = "/ssd/storage",

        DefaultDataRegionConfiguration = new DataRegionConfiguration
        {
            Name = "Default_Region",
            PersistenceEnabled = true
        }
    }
};

Ignition.Start(cfg);

Конфигурация#

В таблице ниже перечислены некоторые свойства класса DataStorageConfiguration.

WAL-журнал#

Изменение размера сегмента WAL-журнала#

Для изменения размера сегмента WAL-журнала выполните следующий код (указывается в serverExampleConfig.xml):

<bean class="org.apache.ignite.configuration.IgniteConfiguration" id="ignite.cfg">

    <property name="dataStorageConfiguration">
        <bean class="org.apache.ignite.configuration.DataStorageConfiguration">

            <!-- Установите размер WAL-сегментов 128 МБ. -->
            <property name="walSegmentSize" value="#{128 * 1024 * 1024}"/>

            <property name="defaultDataRegionConfiguration">
                <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                    <property name="persistenceEnabled" value="true"/>
                </bean>
            </property>

        </bean>
    </property>
</bean>

IgniteConfiguration cfg = new IgniteConfiguration();
DataStorageConfiguration storageCfg = new DataStorageConfiguration();
storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);

storageCfg.setWalSegmentSize(128 * 1024 * 1024);

cfg.setDataStorageConfiguration(storageCfg);

Ignite ignite = Ignition.start(cfg);

Отключение WAL-журнала#

IgniteConfiguration cfg = new IgniteConfiguration();
DataStorageConfiguration storageCfg = new DataStorageConfiguration();
storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);

cfg.setDataStorageConfiguration(storageCfg);

Ignite ignite = Ignition.start(cfg);

ignite.cluster().state(ClusterState.ACTIVE);

String cacheName = "myCache";

ignite.getOrCreateCache(cacheName);

ignite.cluster().disableWal(cacheName);

// Загрузите данные.
ignite.cluster().enableWal(cacheName);

var cacheName = "myCache";
var ignite = Ignition.Start();
ignite.GetCluster().DisableWal(cacheName);
    // Загрузите данные.

ignite.GetCluster().EnableWal(cacheName);

ALTER TABLE Person NOLOGGING

//...

ALTER TABLE Person LOGGING

Сжатие записей WAL-журнала#

IgniteConfiguration cfg = new IgniteConfiguration();

DataStorageConfiguration dsCfg = new DataStorageConfiguration();
dsCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);

// Параметры сжатия страницы WAL.
dsCfg.setWalPageCompression(DiskPageCompression.LZ4);
dsCfg.setWalPageCompressionLevel(8);

cfg.setDataStorageConfiguration(dsCfg);
Ignite ignite = Ignition.start(cfg);

Отключение архива WAL-журнала#

Для отключения архивирования укажите одно и то же значение как для walPath, так и для walArchivePath. В этом случае DataGrid не копирует сегменты в архив. Вместо этого он создает новые сегменты в папке WAL-журнала, а старые сегменты удаляются по мере роста самого WAL-журнала. Этот рост зависит от настроек размера архива WAL-журнала.