[
https://issues.apache.org/jira/browse/SOLR-8561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105095#comment-15105095
]
Shai Erera commented on SOLR-8561:
----------------------------------
I thought that it should, but didn't for two reasons:
1) On the original issue where this issue was introduced (SOLR-7844), writing
the leader props to both "shard1" and "shard1/leader" was done in 5x only,
suggesting that there was no intention for 6.0 to be backward compatible with
5.x in this regard.
2) [[email protected]] made this comment "Yeah, 5x needs a little bridge
back compat that checks the old location if the new one does not exist." which
again, made me think that there was no intention to support such a use case.
Basically I agree with you, if someone will upgrade from 5.3 straight to 6.0,
and will want to do this as a rolling upgrade, then he'll hit that issue. But I
wasn't sure if that scenario is intended to be supported. I'd be happy to port
this fix to trunk as well if people think otherwise.
> Add fallback to ZkController.getLeaderProps for a mixed 5.4-pre-5.4
> deployments
> -------------------------------------------------------------------------------
>
> Key: SOLR-8561
> URL: https://issues.apache.org/jira/browse/SOLR-8561
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Shai Erera
> Assignee: Shai Erera
> Fix For: 5.5, 5.4.1
>
> Attachments: SOLR-8561.patch, SOLR-8561.patch
>
>
> See last comments in SOLR-7844. The latter changed the structure of the
> leader path in ZK such that upgrading from pre-5.4 to 5.4 is impossible,
> unless all nodes are taken down. This issue adds a fallback logic to look for
> the leader properties on the old ZK node, as discussed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
