[
https://issues.apache.org/jira/browse/SOLR-16302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602436#comment-17602436
]
Jason Gerlowski commented on SOLR-16302:
----------------------------------------
I think a WARN message here would definitely be prudent.
It might even be worth adding some sort of flag to the restore API, to govern
whether Solr uses the existing ZK config, or overwrite it upon restoring. Of
course, overwriting the config in ZK is probably a bad idea if the config is
used by multiple collections, or if the collection being restored pre-existed
the RESTORE call. So maybe it's just better to stick with a WARN message here.
Looking at the code, it looks like we log out an [INFO
message|https://github.com/apache/solr/blob/db23d7d48d5ef2cf84ff8f8de38209698db172d4/solr/core/src/java/org/apache/solr/cloud/api/collections/RestoreCmd.java#L323]
already, but nothing super helpful. Any chance you're up for suggesting some
improved wording in a PR, [~almoser]?
> Backup restore silently skips config restore if config with same name already
> exists (in cloud mode)
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-16302
> URL: https://issues.apache.org/jira/browse/SOLR-16302
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
> Affects Versions: 9.0
> Reporter: Albert Moser
> Priority: Minor
>
> We have tested this only in cloud mode.
>
> We have noticed when a backup is restored that contains a config with the
> same name as one that already exists in solr, the config restore is silently
> skipped (also when the configs are different but share the same name). I
> would expect that at least a warning appears in the logs when this happens.
> We saw that this happens with backups from local repositories as well as gcs
> repository (possibly others too).
> Steps to reproduce the issue:
> # Start solr in cloud mode
> # Upload a config (any config, we tried with the default one)
> # Create a collection with the config
> # Create a backup
> # Delete collection in UI
> # Change the config either in backup or in solr (we added an additional
> comment)
> # Restore collection
> # Have a look that after restore the old solr config has remained and the
> restored collection is using it. At the same time, the config from the backup
> has been ignored and no warning was produced whatsoever.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
