[
https://issues.apache.org/jira/browse/SOLR-13584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875548#comment-16875548
]
Erick Erickson commented on SOLR-13584:
---------------------------------------
Hmmm, would the hassle be more manageable if ZK was, indeed, the single source
of truth? Currently, core discovery uses some information in core.properties to
try to figure out where that replica fits in the grand scheme of things. So
things like collection name need to be in core.properties and the info in
core.properties and state.json need to be kept in sync.
What if SolrCloud stored something like a GUID in the core.properties file
rather than collection name and the like? Would that make a true rename easier
by just requiring that the state.json node be updated and possibly the
collections znode for the configname?
This is straw-man, for discussion. It might not even be that invasive (going
from memory here, so be warned). But at some point the core cloud descriptor is
created from the core.properties file. Somehow (tm), if there was a GUID in the
core.properties file we could find the corresponding state.json and "do the
right thing".
Lots of details here, which is why it's straw-man. Off the top of my head I can
see these issues:
* we'd need some migration path, akin to MIGRATESTATE that would assign
IDs/guids to each replica and update core.properties
* Humans read these things, so putting comments in the core.properties for all
the current properties seems good
* It'd be tricky to deal with orphans. I.e. some replica on some node that was
down when the MIGRATESTATE was done. Maybe also add some kind of manual command
that allowed individual replicas to be migrated?
* All this pretty much assumes that once the (cloud) core descriptor is
created properly, the rest of the code that uses it doesn't change much.
* Maybe keep a rename_list in the collections znode to be able to find out
where some replica belongs.
* Hmmm, wait wait wait. Do we really need a GUID/ID or would the coreNodeName
work? That's already unique, at least within a collection, we'd have to check
if it was unique across collections.
* And lots more no doubt, I'm wondering if this seems feasible and whether
it's worth even thinking about....
> Explore prohibiting aliases and collections from having the same name.
> ----------------------------------------------------------------------
>
> Key: SOLR-13584
> URL: https://issues.apache.org/jira/browse/SOLR-13584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Priority: Major
>
> Allowing aliases and collections to have the same name is fragile and a
> potentially a data issue. I'll link in a few JIRAs illustrating this and one
> at least where the discussion gets long.
> Straw-man proposal to start things off.
> Deprecate this ability now, and enforce it in 9.0.
> We have to provide a graceful way for users to get themselves out of the
> following currently-possible use-case.
> * a collection C1 is created and all the front-end uses it.
> * users want to atomically switch to a new collection for various reasons
> * users create C2 and test it out.
> * users create an alias C1->C2
> Let's discuss.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
