集群快照

1.集群快照

1.1.概述

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

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

work
└── snapshots
    └── backup23012020
        └── db
            ├── binary_meta
            │         ├── node1
            │         ├── node2
            │         └── node3
            ├── marshaller
            │         ├── node1
            │         ├── node2
            │         └── node3
            ├── 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目录存储了和元数据和编组器有关的信息。

通常快照分布于整个集群

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

1.2.配置

1.2.1.配置快照目录

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

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

1.2.2.快照执行线程池

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

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

1.3.创建快照

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

1.3.1.使用控制脚本

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

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

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

#Cancel a running snapshot:
control.(sh|bat) --snapshot cancel snapshot_name

#Kill a running snapshot:
control.(sh|bat) --kill SNAPSHOT snapshot_name

1.3.2.使用JMX

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

方法	描述
createSnapshot(String snpName)	创建快照
createSnapshot(String snpName)	在创建快照的发起节点取消快照

1.3.3.使用Java API

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

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

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

    // Start snapshot operation.
    ignite.snapshot().createSnapshot("snapshot_02092020").get();
}
finally {
    ignite.destroyCache(ccfg);
}

1.4.检查快照一致性

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

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

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

1.5.从快照恢复

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

1.5.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.5.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 group "snapshot-cache" from the snapshot "snapshot_02092020".
control.(sh|bat) --snapshot restore snapshot_02092020 --start --groups snapshot-cache

使用命令行控制恢复操作

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

# 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 --start --sync

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

# Get the status of the restore operation for "snapshot_09062021".
control.(sh|bat) --snapshot restore snapshot_09062021 --status

# Cancel the restore operation for "snapshot_09062021".
control.(sh|bat) --snapshot restore snapshot_09062021 --cancel

1.6.一致性保证

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

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

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

1.7.当前的限制

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

• 不支持某个表/缓存的快照，只能创建整个集群的快照；
• 未开启原生持久化的表/缓存，不支持快照；
• 快照中加密的缓存必须使用相同的主密钥进行加密；
• 同时只能执行一个快照操作；
• 在主密钥更改和/或缓存组密钥更改期间，禁止快照操作；
• 如果一个服务端节点离开集群，快照过程会被中断。

18624049226