You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Anilkumar Gingade (Jira)" <ji...@apache.org> on 2020/08/10 18:36:00 UTC
[jira] [Updated] (GEODE-2682) Compaction with async disk writes may
resurrect removed entries
[ https://issues.apache.org/jira/browse/GEODE-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anilkumar Gingade updated GEODE-2682:
-------------------------------------
Labels: GeodeOperationAPI storage_2 (was: storage_2)
> Compaction with async disk writes may resurrect removed entries
> ---------------------------------------------------------------
>
> Key: GEODE-2682
> URL: https://issues.apache.org/jira/browse/GEODE-2682
> Project: Geode
> Issue Type: Bug
> Components: persistence
> Affects Versions: 1.0.0-incubating, 1.1.0
> Reporter: Jason Huynh
> Priority: Major
> Labels: GeodeOperationAPI, storage_2
> Attachments: cache.xml, oplogs.tar.gz
>
>
> This can occur for persistent async event queues and for regions when concurrency checks are disabled.
> Currently->
> 1.) When rolling a crf we create a krf that is based on the current “live” region
> 2.) If removes are being done at the same time, the krf will reflect the current state, where the keys are not part of the krf file
> 3.) Due to the async disk write, the drf has yet to be updated.
> 4.) If the cluster gets shut down before the drf is written to. This can lead to the following scenarios:
> * (No issue) the user recovers with the existing krf/drf/crf files. This works just fine as the krf has reflected the change
> * (Problem!) If the user compacts and then recovers, the removed entries are now resurrected and appear in the region due to the way compaction operates. It ignores the krf and works on a the existing crf/drf files. Because the drf does not reflect removed events, the events are rolled forward from the crf.
> Attached is a set oplogs for a single node prior to compaction and a cache.xml (need to fill in the correct location for the diskstore directory)
> Recovering from this set of oplogs recovers 0 entries for the async event queues.
> If you run offline compaction on the oplogs and recover, there are now entries in the async event queues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)