[
https://issues.apache.org/jira/browse/SOLR-15863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499089#comment-17499089
]
Jason Gerlowski commented on SOLR-15863:
----------------------------------------
bq. I presume these values could be filled in at backup time using the
collections aggregate index size and total segment count
This is true, with the minor caveat that segment files are only one of many
file types that make up an index; {{indexFileCount}} and its twin
{{uploadedIndexFileCount}} should count _all_ index files, not just segments.
I'll try looking at this when I get a few spare minutes.
bq. I also would expect the Lucene version tag to properly represent the
version the index is written in
Right now the code that picks the version string always picks whatever the
latest Lucene version is, without actually looking at header of any of the
Lucene files. Which is for sure a problem if the field was intended to be an
aid for determining Lucene-level index-compatibility, as you suggest. And that
does seem like a useful thing to put in the backup metadata.
But I wonder whether this field might not be about index-compatibility at all,
and instead be there to help backup-readers (i.e. future versions of Solr) deal
with any changes that might be introduced into the structure of the backup
itself. I'd have to do some more digging to verify what the initial aim was
around this field, but the current value makes me suspect it was intended for
the latter use case.
None of this changes the conclusion, IMO: you're right that we should
definitely be storing the version of the actual index files. But figuring out
the initial intent here is important in deciding whether we put that
information in the existing {{indexVersion}} field, or whether we add a new
field to hold that info and leave the existing {{indexVersion}} property as-is.
> Backups do not store correct information in backup_N.properties
> ---------------------------------------------------------------
>
> Key: SOLR-15863
> URL: https://issues.apache.org/jira/browse/SOLR-15863
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
> Reporter: Michael Joyner
> Priority: Major
>
> Example backup_0.properties file from an 8.10.1 created collection backed up
> by 8.11.0 to an S3 repository showing invalid file sizes and incorrect index
> version:
> {{#Backup properties file}}
> {{#Wed Dec 01 20:37:09 UTC 2021}}
> {{indexFileCount=0}}
> {{shard2.md=md_shard2_0.json}}
> {{indexSizeMB=0.0}}
> {{collection.configName=dailies_config_2021-11-15_8_10_1}}
> {{shard1.md=md_shard1_0.json}}
> {{collectionAlias=dailies_2021-11-15_8_10_1}}
> {{startTime=2021-12-01T19\:52\:04.512652Z}}
> {{indexVersion=8.11.0}}
> {{collection=dailies_2021-11-15_8_10_1}}
> {{backupName=dailies}}
>
> Ricard Ruiz Maldonado also notes that when using the
> LocalFileSystemRepository instead of S3 and the behavior is the same.
>
> [https://apachesolr.slack.com/archives/C01GVPZSSK0/p1639020806104800?thread_ts=1638451996.011100&cid=C01GVPZSSK0]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
