[
https://issues.apache.org/jira/browse/SOLR-9269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386789#comment-15386789
]
Hrishikesh Gadre commented on SOLR-9269:
----------------------------------------
[~dsmiley] I have created a pull request. It addresses all the review comments.
All the tests as well as precommit is passing for me.
Thses are your latest comments
Ref:
https://github.com/hgadre/lucene-solr/commit/1ab2b5022a2ed970e0bad733a4bdb284bb7a0830#commitcomment-18106713
Ref:
https://github.com/hgadre/lucene-solr/commit/1ab2b5022a2ed970e0bad733a4bdb284bb7a0830#commitcomment-18106676
bq. I haven't dealt with this class much before; lots of complicated code here.
The code you added seems to be only for a full copy replication, and it appears
that is to a new index dir, hence the existing logic to remove an "old" index
dir. In this circumstance why delete only the non-snapshot index files;
shouldn't we basically remove everything and clear all snapshots? Or, and this
may be complicated, try and retain the snapshots by copying the snapshotted
files from old to new?
bq. This is the only spot that calls deleteSnapshotIndexFiles, and I'm not
completely clear as to its comments above. How would the indexDirPath not be
the core index dir? Or in other words, why does the snapshot commit metadata
have the index dir String when it might be implied as the same as for the Solr
core?
There are some operations (e.g. restore or full replication) where Solr changes
the *current* index directory. When the old index directory before the
operation has snapshots stored, we have two options,
(a) Copy snapshot files to the new directory.
(b) Keep the old directory (and the relevant index files) around until the
snapshot exist. When the snapshot is deleted, cleanup the index files. Note
that this cleanup is performed *only* when the directory containing snapshot
files != the *current* index directory. When directory containing snapshot
files == the *current* index directory, we delegate file management to
IndexDeletionPolicy implementation.
Option (a) is not workable since
- There can be a file naming conflict between files corresponding to index
commit referred by the snapshot and the index commit copied from external
source (e.g. from external backup or some other Solr server).
- Copying files would require more disk I/O which is not really necessary from
Solr perspective (since the snapshot files are just a corpus intended for
backup/restore use-case).
Hence I implemented option (b) in this patch.
bq. BTW if the path does need to continue to be a part of the snapshot
metadata, then that draws suspicion to the isSnapshotted(long) method
signature since it ought to also have the path? Or maybe snapshot metadata
management needs to be fundamentally managed per index dir path?
Yes good catch! I fixed this problem. I also addressed the case of Lucene
segment sharing between multiple index commits as well as multiple snapshots
referring to the same index commit by implementing a reference counting
mechanism. I have added unit tests to verify this behavior as well.
> Ability to create/delete/list snapshots for a solr core
> -------------------------------------------------------
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Hrishikesh Gadre
> Assignee: David Smiley
> Attachments: SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level.
> Please refer to parent JIRA for more details.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
