geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [15/35] geode git commit: GEODE-2994 Take backups when region ops are quiescent
Date Wed, 31 May 2017 23:15:14 GMT
GEODE-2994 Take backups when region ops are quiescent

    This closes #544


Branch: refs/heads/feature/GEODE-2632-19
Commit: c1288ac87f1cdee0e34441ab181eeb0506ad4554
Parents: a416a32
Author: Karen Miller <>
Authored: Fri May 26 10:29:29 2017 -0700
Committer: Karen Miller <>
Committed: Wed May 31 15:01:08 2017 -0700

 .../disk_storage/ | 10 ++++++++++
 .../tools_modules/       | 13 ++++++++-----
 2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/geode-docs/managing/disk_storage/ b/geode-docs/managing/disk_storage/
index 123ae31..deb942b 100644
--- a/geode-docs/managing/disk_storage/
+++ b/geode-docs/managing/disk_storage/
@@ -38,6 +38,16 @@ Do not try to create backup files from a running system by using your operating
 **Preparing to Make a Backup**
 -   Consider compacting your disk store before making a backup. If auto-compaction is turned
off, you may want to do a manual compaction to save on the quantity of data copied over the
network by the backup. For more information on configuring a manual compaction, see [Manual
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asynchronous event queue (AEQ) or a WAN Gateway sender
+(which uses a persistent queue).
+A region operation that causes a persisted write to a region
+involves a disk operation.
+The associated queue operation also causes a disk operation.
+These two disk operations are not made atomically,
+so if a backup is made between the two disk operations,
+then the backup represents inconsistent data in the region and the queue.
 -   Run the backup during a period of low activity in your system. The backup does not block
system activities, but it uses file system resources on all hosts in your distributed system,
and it can affect performance.
 -   Configure each member with any additional files or directories to be backed up by modifying
the member's `cache.xml` file. Additional items that ought to be included in the backup:
diff --git a/geode-docs/tools_modules/ b/geode-docs/tools_modules/
index 457fff7..2788338 100644
--- a/geode-docs/tools_modules/
+++ b/geode-docs/tools_modules/
@@ -296,8 +296,11 @@ will return `object_2`.
 will return `object_3`.
 - Backups should only be made for regions with Lucene indexes
 when there are no puts, updates, or deletes in progress.
-Incremental backups will not be consistent for the region and
-its index upon restart if these operations were in progress,
-due to the delayed processing associated with the asynchronous event queue.
-If region data needs to be restored from a backup,
-follow the same procedure as given for changing an index.
+A backup might cause an inconsistency between region data and a Lucene index.
+Both the region operation and the associated index operation
+cause disk operations,
+yet those disk operations are not done atomically.
+Therefore, if a backup were taken between
+the persisted write to a region
+and the resulting persisted write to the Lucene index,
+then the backup represents inconsistent data in the region and Lucene index.

View raw message