I think this is an edge case that we can document in the upgrade notes. Saying "If you plan on doing restores during a minor version upgrade, please upgrade to this version before moving to a more recent version of 9.x". Restores are fairly infrequent, and it'd be sad to defer the benefit all the way to 10.
Though we would need a minor version that didn't include the RestoreCmd changes, so there would be an intermediary version for users to use. In situations like this, it'd be nice if inter-node Solr communication > passed version numbers back & forth. > That would be very very nice. - Houston On Mon, Oct 2, 2023 at 8:04 PM David Smiley <david.w.smi...@gmail.com> wrote: > 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 >
