https://issues.apache.org/jira/browse/SOLR-16924
There is a small improvement planned for Collection restore (from backup) internal sequencing, and I have a question for the group on backwards compatibility. The RestoreCmd will no longer need to send a REQUESTAPPLYUPDATES command to each core following RESTORECORE because RESTORECORE will now finish fully active. If we ship this as-is then there could be an issue during a live upgrade-in-place. RestoreCmd might be running the latest release but another node (where a core is being restored) might be older and thus the state of the UpdateLog inside the restored core might not be active. The restoration will complete seemingly successfully yet indexing won't work. The user should just try the restore again (after the upgrade). Hopefully the user would be more alert to problems, having just did an in-place upgrade. I suppose to mitigate this risk, we could defer the ideal benefit to Solr 10 -- deferring the RestoreCmd change until then. But now (9.x) enhance RESTORECORE to flip the UpdateLog state itself. Does this sound fine? Or over-careful? In situations like this, it'd be nice if inter-node Solr communication passed version numbers back & forth. ~ David
