You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ignite.apache.org by GitBox <gi...@apache.org> on 2020/08/06 15:59:23 UTC
[GitHub] [ignite] Mmuzaf opened a new pull request #8128: IGNITE-12968 Snapshot documentation pages
Mmuzaf opened a new pull request #8128:
URL: https://github.com/apache/ignite/pull/8128
Thank you for submitting the pull request to the Apache Ignite.
In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:
### The Contribution Checklist
- [ ] There is a single JIRA ticket related to the pull request.
- [ ] The web-link to the pull request is attached to the JIRA ticket.
- [ ] The JIRA ticket has the _Patch Available_ state.
- [ ] The pull request body describes changes that have been made.
The description explains _WHAT_ and _WHY_ was made instead of _HOW_.
- [ ] The pull request title is treated as the final commit message.
The following pattern must be used: `IGNITE-XXXX Change summary` where `XXXX` - number of JIRA issue.
- [ ] A reviewer has been mentioned through the JIRA comments
(see [the Maintainers list](https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers))
- [ ] The pull request has been checked by the Teamcity Bot and
the `green visa` attached to the JIRA ticket (see [TC.Bot: Check PR](https://mtcga.gridgain.com/prs.html))
### Notes
- [How to Contribute](https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute)
- [Coding abbreviation rules](https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules)
- [Coding Guidelines](https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines)
- [Apache Ignite Teamcity Bot](https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot)
If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com _#ignite_ channel.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] dmagda merged pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
dmagda merged pull request #8128:
URL: https://github.com/apache/ignite/pull/8128
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484834112
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484866770
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -3,33 +3,40 @@
== Overview
Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
-the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
-of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
-structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
-on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
-contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups is stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
-*Snapshot Consistency.*
+=== Snapshot Consistency
-All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
-system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
snapshots.
-The cluster-wide snapshot consistency achieved by triggering the
+The cluster-wide snapshot consistency is achieved by triggering the
link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
-procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
-finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation will be initiated.
Review comment:
Fixed
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -62,25 +69,25 @@ work
└── marshaller
----
-*Requirements.*
+=== Requirements
-You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
-This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation completes.
Review comment:
Fixed
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -62,25 +69,25 @@ work
└── marshaller
----
-*Requirements.*
+=== Requirements
-You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
-This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation completes.
-*Limitations.*
+=== Limitations
-The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
-* taking a snapshot of particular cache or cache group not supported;
-* in-memory caches will not be included into snapshot;
-* encrypted caches not supported and will be ignored;
-* only single snapshot operation can be started at once;
-* snapshot procedure will be interrupted if any baseline node leave the cluster;
-* snapshot recovery at the same baseline topology with the same consistent node id;
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be started;
Review comment:
Fixed
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484832502
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484827734
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484829561
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
Review comment:
Fixed like this one
```
The destination snapshot directory can be configured via `IgniteConfiguration`.
```
since only the destination directory can be configured through configuration.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484832861
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484830646
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Silberfuchs1 commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Silberfuchs1 commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484335614
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
Review comment:
'for each node' maybe? The data is stored on disk in files for each node?
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
Review comment:
At runtime, you can create multiple snapshots of all configured persistent cache groups.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
Review comment:
don't understand, where 'procedure' goes... Is 'triggering the link' the procedure?
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
Review comment:
'... finished...' ---> '...are finished...'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
Review comment:
encrypted caches are not supported and will be ignored;
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
Review comment:
in order to recover the data from a particular snapshot, you need to start the same cluster with the same configuration...
'configuration on these files.' - which files? Data files? Then maybe 'in these files'? Or 'of these files'?
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
Review comment:
'stored' ---> 'is stored'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
Review comment:
'...will be also fully consistent...' ---> '...will also be fully consistent...'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
Review comment:
'ids' ---> 'IDs'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
Review comment:
'... achieved...' ---> 'is achieved'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
Review comment:
'...you created' ---> 'you've created'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
Review comment:
'...(cache group partition files, configuration files, binary metadata), the snapshot will...'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
Review comment:
'...with your own production environment:'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
Review comment:
'will require'? Why not 'requires' or 'may require', or 'might require'?
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
Review comment:
in-memory caches will not be included into a snapshot;
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
Review comment:
Didn't understand the sentence. what does '... as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory.' mean?
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
Review comment:
This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
Review comment:
A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
Review comment:
'The **consistency of local system files** (e.g. cache group partition files, binary metadata files, configuration files) **is** achieved....'
or
'The **local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency** **is** achieved....'
Otherwise, the types of local system files are away from the definition itself, and the reader could get confused.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
Review comment:
you can start only one snapshot operation at a time;
My question is: is the snapshot operation started automatically, or it can be started manually?
If the answer is 'automatically', then you need to say: 'only one snapshot operation can be started at once' or
'only one snapshot operation at a time can be started'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
Review comment:
Didn't understand the sentence. Looks like it's not finished.
Maybe like this: 'snapshot recovery is performed at the same baseline topology with the same node consistent Id.'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
Review comment:
...leaves the cluster
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
Review comment:
taking a snapshot of a particular cache or cache group is not supported;
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
Review comment:
Copy all snapshot files from the snapshot related to `{node_id}` to the `$IGNITE_HOME/work/{node_id}` directory;
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
Review comment:
The destination snapshot can be configured via `IgniteConfiguration`.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
Review comment:
It'd be better to name this section like 'Cluster restoring from a snapshot (manual)'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
Review comment:
'...act like a tool...'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
Review comment:
NOTE: Removing data from the `$IGNITE_HOME/work` directory is performed at your own risk.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
Review comment:
started ---> initiated maybe?
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
Review comment:
'...currently running one via...'
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
Review comment:
...a consistent id of a node you work with;
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
Review comment:
Here are some options:
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
Review comment:
... the data recovery procedure...
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process will
+require the cluster to be rebalanced and SQL indexes to be rebuilt which may take a long time.
+|m > n | Currently, not supported.
Review comment:
Currently, it is not supported.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
Review comment:
Locate the snapshot you've created by name;
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
Review comment:
Use the same baseline and configuration.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process will
+require the cluster to be rebalanced and SQL indexes to be rebuilt which may take a long time.
Review comment:
The process will require the cluster to be rebalanced and SQL indexes to be rebuilt. These operations may take a long time.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
Review comment:
To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484826267
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
Review comment:
`Restoring from a snapshot (manual)` is better I suppose since we always restore a cluster.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484837143
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484826689
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
Review comment:
Fixed
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
Review comment:
Fixed
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484830785
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484835019
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r489328523
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
Review comment:
Agree, fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484840811
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484827806
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process will
+require the cluster to be rebalanced and SQL indexes to be rebuilt which may take a long time.
Review comment:
Fixed.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
+
+To restore a cluster from the snapshot you must do the following steps for each baseline node in it:
+
+- Locate by name the snapshot you created;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent node id which do you work with;
+- Copy all snapshot files to the `$IGNITE_HOME/work/{node_id}` directory from the snapshot related to `{node_id}`;
+
+Some use cases at production deployments may require creating a snapshot at m-node cluster and applying it to n-node
+cluster. There are a few options here:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and the same configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process will
+require the cluster to be rebalanced and SQL indexes to be rebuilt which may take a long time.
+|m > n | Currently, not supported.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r489328817
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484838460
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484841546
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r489327998
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
+(see link:#snapshot-structure[Snapshot Structure] for details).
+
+To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
+
+- Locate the snapshot you've created by name;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent id of a node you work with;
+- Copy all snapshot files from the snapshot related to `{node_id}` to the $IGNITE_HOME/work/{node_id} directory;
Review comment:
We should remove and copy from the snapshot all the files for each {nodeId}, all files related to crash-recovery must be removed (wal, checkpoint)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484838711
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484829561
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
Review comment:
Fixed like this one
{code}
The destination snapshot directory can be configured via `IgniteConfiguration`.
{code}
since only destination directory can be configured through configuration.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484828072
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] dmagda commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
dmagda commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r489041825
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
Review comment:
Can we replace "persistent cache groups" with "cache" or "cache and tables", or "data"? The term "persistent cache groups" are not widespread among the user community and can cause confusion.
For instance, in this sentence you can say:
"You can create multiple snapshots of all the data stored in your cluster"
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
Review comment:
You can simply say "node" instead of "baseline node" as long as all the nodes have to be in a baseline topology when the persistence is used.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
Review comment:
Check this page for an example of how to create NOTE callouts (search for the NOTE occurrence):
https://raw.githubusercontent.com/apache/ignite/IGNITE-7595/docs/_docs/quick-start/java.adoc
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
+(see link:#snapshot-structure[Snapshot Structure] for details).
+
+To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
+
+- Locate the snapshot you've created by name;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent id of a node you work with;
+- Copy all snapshot files from the snapshot related to `{node_id}` to the $IGNITE_HOME/work/{node_id} directory;
+
+Some use cases at production deployments may require creating a snapshot at the m-node cluster and applying it to the
+n-node cluster. Here are some options:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process
Review comment:
Let's say I had 5 nodes in the N-cluster and trying to apply the snapshot to a 3-node cluster (the m-cluster). I will copy the snapshot files from the first 3 nodes of the N-cluster to the M-cluster. But what should I do with the snapshot files of the other 2 nodes of the N-cluster? Basically, what's the procedure for squeezing 5 folders (N-cluster) with the snapshots into the 3 folders (M-cluster). That's unclear to me.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
+(see link:#snapshot-structure[Snapshot Structure] for details).
+
+To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
+
+- Locate the snapshot you've created by name;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent id of a node you work with;
+- Copy all snapshot files from the snapshot related to `{node_id}` to the $IGNITE_HOME/work/{node_id} directory;
Review comment:
Do we need to replace the files from the entire work dir or is it enough to do this procedure with {WORK_DIR}/db?
Also, you should take into account a use case when the storage path is overridden via DataStorageConfiguration.storagePath parameter.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
Review comment:
Below we are saying that the restore procedure is manual. I would add an item to the limitations list saying that the automatic restore is not available yet.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
Review comment:
Just merge this "Requirements" section with the "Configuration" section below. They talk about the same thing.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
Review comment:
"you need to start each node of the same cluster on these files..."
I would say
"you need restart every cluster node swapping its current data from the "{IGNITE_WORK_DIR}/db" directory with the data from the snapshot"
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
+(see link:#snapshot-structure[Snapshot Structure] for details).
+
+To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
+
+- Locate the snapshot you've created by name;
Review comment:
Should we mention that the entire cluster must be stopped before the restore procedure?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484838959
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r489326567
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
+(see link:#snapshot-structure[Snapshot Structure] for details).
+
+To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
+
+- Locate the snapshot you've created by name;
+- Remove all the data from `$IGNITE_HOME/work/{node_id}` where `{node_id}` is a consistent id of a node you work with;
+- Copy all snapshot files from the snapshot related to `{node_id}` to the $IGNITE_HOME/work/{node_id} directory;
+
+Some use cases at production deployments may require creating a snapshot at the m-node cluster and applying it to the
+n-node cluster. Here are some options:
+
+[cols="1,1",opts="header"]
+|===
+|Condition | Description
+|m == n | The *recommended* case. Use the same baseline and configuration.
+|m < n | Start the m-node cluster from the snapshot and add additional nodes to the started baseline. The process
Review comment:
Denis,
- the m-cluster is the source of a snapshot (take from)
- the n-cluster is the destination (apply to)
case `m > n` is not supported yet, since, as you mentioned before, `squeezing` procedures are not developed yet.
case `m < n` start m-cluster from a snapshot and add additional nodes to it by changing baseline.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484832243
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
Review comment:
I don't feel the difference, what's the point? Snapshot operations are always starting by the user through the available API. I think the correct sentence is `only one snapshot operation at a time can be started` as you suggested.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484836802
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Silberfuchs1 commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Silberfuchs1 commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484858407
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -62,25 +69,25 @@ work
└── marshaller
----
-*Requirements.*
+=== Requirements
-You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
-This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation completes.
Review comment:
after the snapshot operation is completed.
It is so, because when you say ' completes', the reader will think 'completes doing what?'.
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -3,33 +3,40 @@
== Overview
Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
-the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
-of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
-structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
-on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
-contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups is stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
-*Snapshot Consistency.*
+=== Snapshot Consistency
-All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
-system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
snapshots.
-The cluster-wide snapshot consistency achieved by triggering the
+The cluster-wide snapshot consistency is achieved by triggering the
link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
-procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
-finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation will be initiated.
Review comment:
...is initiated
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -62,25 +69,25 @@ work
└── marshaller
----
-*Requirements.*
+=== Requirements
-You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
-This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation completes.
-*Limitations.*
+=== Limitations
-The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
-* taking a snapshot of particular cache or cache group not supported;
-* in-memory caches will not be included into snapshot;
-* encrypted caches not supported and will be ignored;
-* only single snapshot operation can be started at once;
-* snapshot procedure will be interrupted if any baseline node leave the cluster;
-* snapshot recovery at the same baseline topology with the same consistent node id;
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be started;
Review comment:
if 'operation' than 'initiated'. Let's do so throughout the document.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484838178
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
Review comment:
The sentence will be compiled to this one:
```
The cluster-wide snapshot consistency achieved by triggering the Partition-Map-Exchange procedure.
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r489326656
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,188 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. At runtime, you can create multiple snapshots of all
+configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since the data of persistent cache groups are stored
+on disk in files for each node (cache group partition files, configuration files, binary metadata) in a cluster,
+the snapshot will contain a copy of the same files with keeping Ignite cluster node data directory structure and node consistent IDs.
+
+=== Snapshot Consistency
+
+All snapshots you've created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will also be fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency is achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions are
+finished on primary and backups, and new ones are hold until a new snapshot operation is initiated.
+
+The local system files (e.g. cache group partition files, binary metadata files, configuration files) consistency is achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files might require additional space in the Ignite work directory.
+
+=== Snapshot Structure
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in the snapshot directory. The `wal` and `checkpoint`
+directories will be excluded from the snapshot since recovery procedures are not necessary for cache group data files.
+
+The created snapshot contains:
+
+- cache group partition files;
+- cache configuration files related to cache groups;
+- binary metadata files;
+- marshaller data files;
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+=== Requirements
+
+A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
+This space will be used for storing intermediate snapshot results and cleaned up after the snapshot operation is completed.
+
+=== Limitations
+
+The snapshot procedure has some limitations that you should be aware of before using it within your production environment:
+
+* taking a snapshot of a particular cache or cache group is not supported;
+* in-memory caches will not be included into a snapshot;
+* encrypted caches are not supported and will be ignored;
+* only one snapshot operation at a time can be initiated;
+* snapshot procedure will be interrupted if any baseline node leaves the cluster;
+* snapshot may be restored only at the same baseline topology with the same node consistent IDs;
+
+== Configuration
+
+The destination snapshot directory can be configured via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that act like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running one via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Restoring from a snapshot (manual)
+
+NOTE: Removing data from the $IGNITE_HOME/work directory performed at your own risk.
+
+Currently, the data restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+in order to recover from the particular snapshot, you need to start each node of the same cluster on these files
+(see link:#snapshot-structure[Snapshot Structure] for details).
+
+To restore a cluster from a snapshot, the following steps should be performed for each baseline node in it:
+
+- Locate the snapshot you've created by name;
Review comment:
Yes, fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484835962
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
Review comment:
This is how the sentence will look like after the page will be compiled:
```
A configured Ignite native persistence directory requires additional disk space (up to the current size of this directory).
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484837472
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484827658
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
+* encrypted caches not supported and will be ignored;
+* only single snapshot operation can be started at once;
+* snapshot procedure will be interrupted if any baseline node leave the cluster;
+* snapshot recovery at the same baseline topology with the same consistent node id;
+
+== Configuration
+
+You may configure the destination snapshot directory via `IgniteConfiguration`.
+
+[tabs]
+--
+tab:XML[]
+
+[source, xml]
+----
+include::code-snippets/xml/snapshots.xml[tags=ignite-config;!discovery, indent=0]
+
+----
+
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=config, indent=0]
+
+----
+
+tab:C#/.NET[]
+tab:C++[]
+--
+
+== Snapshot creation
+
+Ignite provides the ability to start a snapshot operation from the following interfaces:
+
+- link:#command-line[Command line]
+- link:#jmx[JMX]
+- link:#java-api[Java API]
+
+=== Command line
+
+Ignite ships `control.(sh|bat)` scripts, located in the `$IGNITE_HOME/bin` directory, that acts like a tool to
+start or cancel snapshot operation from the command line. The following commands can be used with `control.(sh|bat)`:
+
+[source,shell]
+----
+#Create cluster snapshot:
+control.(sh|bat) --snapshot create snapshot_name
+
+#Cancel running snapshot:
+control.(sh|bat) --snapshot cancel snapshot_name
+
+#Kill running snapshot:
+control.(sh|bat) --kill SNAPSHOT snapshot_name
+----
+
+=== JMX
+
+You can start snapshot operation or cancel currently running via the `SnapshotMXBean` interface:
+
+[cols="1,1",opts="header"]
+|===
+|Method | Description
+|createSnapshot(String snpName) | Create cluster-wide snapshot.
+|cancelSnapshot(String snpName) | Cancel started cluster-wide snapshot on the node initiator.
+|===
+
+=== Java API
+
+The snapshot operation can be started using Java API:
+
+[tabs]
+--
+tab:Java[]
+
+[source, java]
+----
+include::{javaCodeDir}/Snapshots.java[tags=create, indent=0]
+----
+--
+
+== Snapshot restore (manually)
+
+NOTE: Pay attention in case of removing any data from the `$IGNITE_HOME/work` directory. You do it at your own risk.
+
+Currently, the restore procedure is fully manual. Since the snapshot is a consistent copy of all data files for each node,
+to recover from the particular snapshot you need to start the same cluster with the same configuration on these files.
Review comment:
I've added a link to the `Snapshot Structure` header and also added the list of data files included into snapshot.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484832625
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
+be excluded from snapshot since recovery procedures are not necessary for cache group data files.
+
+.Example of snapshot directory structure
+[source,shell]
+----
+work
+└── snapshots
+ └── backup23012020
+ ├── binary_meta
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ ├── db
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest0
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-3.bin
+ │ │ ├── part-4.bin
+ │ │ └── part-6.bin
+ │ ├── snapshot_IgniteClusterSnapshotSelfTest1
+ │ │ └── cache-txCache
+ │ │ ├── cache_data.dat
+ │ │ ├── part-1.bin
+ │ │ ├── part-5.bin
+ │ │ └── part-7.bin
+ │ └── snapshot_IgniteClusterSnapshotSelfTest2
+ │ └── cache-txCache
+ │ ├── cache_data.dat
+ │ ├── part-0.bin
+ │ └── part-2.bin
+ └── marshaller
+----
+
+*Requirements.*
+
+You need an extra space on disk for the configured Ignite native persistence directory up to the current size this directory.
+This space will be used for storing intermediate snapshot results and will be freed when the snapshot operation ends.
+
+*Limitations.*
+
+The snapshot procedure has some limitations that you should be aware of before using it at your production environment:
+
+* taking a snapshot of particular cache or cache group not supported;
+* in-memory caches will not be included into snapshot;
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484837576
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484838314
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
Review comment:
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite] Mmuzaf commented on a change in pull request #8128: IGNITE-12968 Snapshot documentation pages
Posted by GitBox <gi...@apache.org>.
Mmuzaf commented on a change in pull request #8128:
URL: https://github.com/apache/ignite/pull/8128#discussion_r484835962
##########
File path: docs/_docs/persistence/snapshot.adoc
##########
@@ -0,0 +1,181 @@
+= Snapshots and recovery
+
+== Overview
+
+Apache Ignite 2.9 comes with an ability to create fully consistent cluster-wide snapshots for deployments with
+the link:persistence/native-persistence[Ignite Native Persistence]. You can create at runtime any number of snapshots
+of all configured persistent cache groups. The snapshot is a consistent copy of all cache group data files (except
+structures used for crash recovery) for each baseline node in a cluster. Since data of persistent cache groups stored
+on disk in files on each node (cache group partition files, configuration files, binary metadata) the snapshot will
+contain a copy of the same files with keeping Ignite cluster node data directory structure and the node consistent ids.
+
+*Snapshot Consistency.*
+
+All snapshots you created are fully consistent in terms of concurrent cluster-wide operations and all ongoing changes of
+system files on the local node. Primary and backup cache group partitions will be also fully consistent in created
+snapshots.
+
+The cluster-wide snapshot consistency achieved by triggering the
+link:https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood[Partition-Map-Exchange]
+procedure. Doing this the cluster will eventually get a point in time when all previously started transactions
+finished on primary and backups, and new ones are hold until a new snapshot operation will be started.
+
+The local system files consistency (e.g. cache group partition files, binary metadata files, configuration files) achieved
+by copying them to the destination snapshot directory with tracking all concurrent ongoing changes. Tracking concurrent
+changes during copying of cache group partition files will require additional space in Ignite system directory.
+
+*Snapshot Structure.*
+
+The created snapshot has the same
+link:https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStoreunderthehood-FoldersStructure[Directory Structure]
+as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory. The `wal` directory will
Review comment:
This is how the sentence will look like after the page will be compiled:
```
The created snapshot has the same Directory Structure as the Ignite native persistence does with keeping nodes `consistentId` in snapshot directory.
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org