集群快照

1.集群快照

1.1.概述

对于开启了原生持久化的集群，Ignite提供了创建集群全量和增量快照的功能。一个Ignite快照包括了整个集群中所有存盘数据的完整一致副本，以及用于恢复过程必需的其他一些文件。

快照的结构除了一些例外，类似于Ignite原生持久化存储目录的布局，以下面的快照为例，看一下结构：

work
└── snapshots
    └── backup23012020
        ├── 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

• 快照位于work\snapshots目录下，名为backup23012020，这里work是Ignite的工作目录；
• 创建快照的集群有3个节点，所有节点都在同一台主机上运行。在此示例中，节点分别名为node1、node2和node3，而实际上，它们的名字是节点的一致性ID；
• 快照保留了my-sample-cache缓存的副本；
• db文件夹在part-N.bin和cache_data.dat文件中保留数据记录的副本。预写日志和检查点不在快照中，因为这些在全量快照的恢复过程中并不需要；
• binary_meta和marshaller目录存储了和元数据和编组器有关的信息；
• increments文件夹存储了基于backup23012020完整快照的增量快照。在本示例中，这里只有一个增量：0000000000000001。它包含一个wal目录，里面存储了压缩后的WAL段，binary_meta和marshaller目录。

通常快照分布于整个集群

上面的示例显示为同一个集群创建的快照运行于同一台物理机，因此整个快照位于一个位置上。实际上，集群中不同主机的所有节点上都会有快照数据。每个节点都持有快照的一段，即归属于该节点的数据快照，恢复过程会说明恢复时如何将所有段合并在一起。

1.2.增量快照

使用完整的快照很难实现低RPO（恢复点对象），例如几分钟。它们需要额外的资源来创建和存储所有分区数据，这时就可以使用增量快照：

1. 存储之前创建的全量或者增量快照之后发生的数据更新；
2. 提供轻量级的创建过程，并且可以与生产负载同时运行。

提示

增量快照由压缩的WAL段组成，这些段在后台收集，不会对集群资源造成压力。

使用增量快照的前提条件：

• 增量快照基于某个已有的全量快照；
• 启用了WAL存档压缩；
• 增量快照需要需要创建在和WAL存档相同的媒体介质上。

在增量快照恢复过程中，首先恢复全量快照，然后依次恢复所有增量快照。

1.3.配置

1.3.1.配置快照目录

快照默认存储在相应Ignite节点的工作目录中，并和Ignite持久化保存数据、索引、WAL和其他文件使用相同的存储介质。因为快照消耗了和持久化相当的空间，然后和Ignite持久化进程共享磁盘IO，从而会影响应用的性能，因此建议将快照和持久化文件存储在不同的存储介质上。

配置方式可以参见配置快照目录。

1.3.2.快照执行线程池

快照线程池大小默认值为4，减少快照创建过程中涉及的线程数会增加快照的总时间。但是这样可以将磁盘负载保持在合理的范围内。

有关细节请参见快照线程池的相关章节。

1.3.3.全局参数

下表列出的全局参数，可以在运行时对快照进行配置：

参数	描述	默认值
snapshotTransferRate	快照传输速率限制（字节/秒）	0

1.3.4.系统参数

下表列出的系统参数，可以对快照进行配置：

属性	类型	描述	默认值
IGNITE_SNAPSHOT_SEQUENTIAL_WRITE	Boolean	快照过程中的磁盘写入应尽可能按顺序进行的标志，这会产生额外的磁盘空间使用量。	true

1.4.创建快照

Ignite提供了几个API来进行快照的创建，下面看下所有的选项：

1.4.1.使用控制脚本

Ignite自带的控制脚本支持和快照有关的操作，如下所示：

# Create a cluster snapshot named "snapshot_09062021" in the background:
control.(sh|bat) --snapshot create snapshot_09062021

# Create a cluster snapshot named "snapshot_09062021" and wait for the entire operation to complete:
control.(sh|bat) --snapshot create snapshot_09062021 --sync

# Create a cluster snapshot named "snapshot_09062021" in the "/tmp/ignite/snapshots" folder (the full path to the snapshot files will be /tmp/ignite/snapshots/snapshot_09062021):
control.(sh|bat) --snapshot create snapshot_09062021 --dest /tmp/ignite/snapshots

# Create an incremental snapshot based on full snapshot "snapshot_09062021":
control.(sh|bat) --snapshot create snapshot_09062021 --incremental

1.4.2.使用JMX

使用SnapshotMXBean接口，可以通过JMX执行和快照有关的过程：

方法	描述
createSnapshot(String snpName, String snpPath)	创建快照
createIncrementalSnapshot(String snpName, String snpPath)	创建增量快照

1.4.3.使用Java API

也可以通过Java API通过编程式创建快照：

CacheConfiguration<Integer, String> ccfg = new CacheConfiguration<>("snapshot-cache");

try (IgniteCache<Integer, String> cache = ignite.getOrCreateCache(ccfg)) {
    cache.put(1, "Maxim");

    // Create snapshot operation.
    ignite.snapshot().createSnapshot("snapshot_02092020").get();

    // Create incremental snapshot operation.
    ignite.snapshot().createIncrementalSnapshot("snapshot_02092020").get();
}
finally {
    ignite.destroyCache(ccfg.getName());
}

1.5.检查快照一致性

通常所有的集群节点都运行在不同的主机上，并且快照数据分布在整个集群中。每个节点都存储自己的快照段，因此在某些情况下，可能需要在从快照恢复之前检查快照的数据完整性和整个集群的数据一致性。

对于这种情况，Ignite提供了内置的快照一致性检查命令，使用户能够验证内部数据一致性、计算数据分区哈希和页面校验和，并在发现问题时输出结果。检查命令还将主分区的哈希值与相应的备份分区进行比较，并报告任何差异。

具体请参见控制脚本中和快照有关的检查命令。

1.6.从快照恢复

快照可以在停止的集群上手动恢复，也可以在在线的集群上自动恢复，下面会介绍这两个过程，但是最好是使用控制脚本的restore命令。

1.6.1.手工恢复过程

快照的结构类似于Ignite原生存储的布局，因此对于手动快照恢复，必须仅在具有相同节点consistentId的同一集群上以及在其上生成快照的同一拓扑上执行快照恢复。只有全量快照才可以恢复。如果需要在不同的集群或不同集群拓扑上恢复快照，或者恢复增量快照，需使用自动快照恢复过程。

通常，停止集群，然后用快照中的数据替换持久化数据和其他文件，并重新启动节点即可。

详细过程如下：

1. 停止要恢复的集群；
2. 从检查点目录$IGNITE_HOME/work/cp中删除所有文件；
3. 在每个节点上执行以下操作：
   • 从$IGNITE_HOME/work/db/binary_meta目录中删除和{consistentId}有关的文件；
   • 从$IGNITE_HOME/work/db/marshaller目录中删除和{consistentId}有关的文件；
   • 从$IGNITE_HOME/work/db目录中删除和{consistentId}有关的文件和子目录，如果该目录不是位于Ignite的work目录下，需要单独清空db/{consistentId}目录；
   • 将快照中属于{consistentId}节点的文件复制到$IGNITE_HOME/work/目录中。如果db/{consistentId}目录不在Ignite的work目录下，则应在对应目录复制数据文件。
4. 重启集群。

1.6.2.自动快照恢复过程

自动恢复过程允许用户使用Java API或命令行脚本从在线集群上的快照恢复缓存组。

目前此过程有几个限制，将在未来版本中解决：

• 仅当快照的所有部分都存在于集群中时才可能进行恢复，每个节点通过给定的快照名称和节点的一致性ID在配置的快照路径中查找本地快照数据；
• 还原过程只能应用于用户创建的缓存组；
• 要从快照恢复的缓存组不得存在于集群中。如果已存在，则必须在开始此操作之前由用户销毁它们；
• 不允许并发恢复操作。因此如果一个操作已经开始，另一个只能在第一个操作完成后开始。

从快照恢复缓存组

以下代码片段演示了如何从快照恢复单个缓存组：

// Restore cache named "snapshot-cache" from the snapshot "snapshot_02092020".
ignite.snapshot().restoreSnapshot("snapshot_02092020", Collections.singleton("snapshot-cache")).get();

// Restore cache named "snapshot-cache" from the snapshot "snapshot_02092020" and its increment with index 1.
ignite.snapshot().restoreSnapshot("snapshot_02092020", Collections.singleton("snapshot-cache"), 1).get();

# Restore cache group "snapshot-cache" from the snapshot "snapshot_02092020".
control.(sh|bat) --snapshot restore snapshot_02092020 --groups snapshot-cache

# Restore cache group "snapshot-cache" from the snapshot "snapshot_02092020" and its increment with index 1.
control.(sh|bat) --snapshot restore snapshot_02092020 --groups snapshot-cache --increment 1

使用命令行控制恢复操作

control.sh|bat脚本提供启动、停止恢复操作的功能。

# Start restoring all user-created cache groups from the snapshot "snapshot_09062021" in the background.
control.(sh|bat) --snapshot restore snapshot_09062021

# Start restoring all user-created cache groups from the snapshot "snapshot_09062021" and wait for the entire operation to complete.
control.(sh|bat) --snapshot restore snapshot_09062021 --sync

# Start restoring all user-created cache groups from the snapshot "snapshot_09062021" located in the "/tmp/ignite/snapshots" folder (the full path to the snapshot files should be /tmp/ignite/snapshots/snapshot_09062021):
control.(sh|bat) --snapshot restore snapshot_09062021 --src /tmp/ignite/snapshots

# Start restoring only "cache-group1" and "cache-group2" from the snapshot "snapshot_09062021" in the background.
control.(sh|bat) --snapshot restore snapshot_09062021 --groups cache-group1,cache-group2

# Start restoring all user-created cache groups from the snapshot "snapshot_09062021" and its increment with index 1.
control.(sh|bat) --snapshot restore snapshot_09062021 --increment 1

1.7.获取快照操作状态

集群当前快照操作的状态，可以通过control.sh|bat脚本或者JMX接口获得。

# Get the status of the snapshot operation.
control.sh --snapshot status

# Get the status of the snapshot operation.
control.bat --snapshot status

SnapshotMXBean mxBean = ...;

// The status of a current snapshot operation in the cluster.
String status = mxBean.status();

1.8.取消快照操作

要中止创建/恢复快照操作，需要获取一个操作请求ID。当使用命令行启动快照操作时，会显示此标识符。它也可以使用status命令和快照指标来获得。

# Cancel a running snapshot operation with ID "9ec229f1-e0df-41ff-9434-6f08ba7d05bd":
control.sh --snapshot cancel --id 9ec229f1-e0df-41ff-9434-6f08ba7d05bd

# Kill a running snapshot operation with ID "9ec229f1-e0df-41ff-9434-6f08ba7d05bd":
control.sh --kill SNAPSHOT 9ec229f1-e0df-41ff-9434-6f08ba7d05bd

# Cancel a running snapshot operation with ID "9ec229f1-e0df-41ff-9434-6f08ba7d05bd":
control.bat --snapshot cancel --id 9ec229f1-e0df-41ff-9434-6f08ba7d05bd

# Kill a running snapshot operation with ID "9ec229f1-e0df-41ff-9434-6f08ba7d05bd":
control.bat --kill SNAPSHOT 9ec229f1-e0df-41ff-9434-6f08ba7d05bd

SnapshotMXBean mxBean = ...;

// Cancel a running snapshot operation with ID "9ec229f1-e0df-41ff-9434-6f08ba7d05bd":
mxBean.cancelSnapshotOperation("9ec229f1-e0df-41ff-9434-6f08ba7d05bd");

1.9.一致性保证

在Ignite的持久化文件、索引、模式、二进制元数据、编组器以及节点的其他文件上的并发操作以及正在进行的修改，所有的快照都是完全一致的。

集群范围的快照一致性是通过触发分区映射交换过程实现的，通过这样做，集群最终达到的状态是所有之前发起的事务全部完成，新的事务全部暂停，这个过程结束之后，集群就会发起快照创建过程，PME过程会确保主备之间的快照一致性。

Ignite持久化文件与其快照副本之间的一致性是通过将原始文件复制到目标快照目录并跟踪所有正在进行的更改来实现的，跟踪更改可能需要额外的空间（最多为存储介质的1倍大小）。

1.9.1.增量快照的一致性保证

增量快照使用基于一致切割算法的非阻塞方法来实现事务一致性。这可以在不影响生产集群性能的情况下启动增量快照，但并不能保证原子缓存的一致性。因此建议在恢复后使用idle_verify命令验证这些缓存，如有必要，可以使用consistency命令修复不一致的分区。

1.10.当前的限制

快照过程有若干限制，如果要用于生产环境需要事先了解如下信息：

• 不支持某个表/缓存的快照，只能创建整个集群的快照；
• 未开启原生持久化的表/缓存，不支持快照；
• 快照中加密的缓存必须使用相同的主密钥进行加密；
• 同时只能执行一个快照操作；
• 在主密钥更改和/或缓存组密钥更改期间，禁止快照操作；
• 如果一个服务端节点离开集群，快照过程会被中断；
• 从具有默认设置allowOverwrite(false)的DataStreamer到持久化缓存的并发更新可能会导致缓存数据不一致。

1.10.1.增量快照的限制

如下场景增量快照无法创建：

• 集群中存在加密的缓存；
• 全量快照创建后缓存被创建、变更或者销毁；
• 集群数据再平衡之后。

Ignite会自动监控这些事件并阻止增量快照创建。只有创建一个新的全量快照之后，才能继续创建增量快照。

18624049226