Makes sense. I added a generic note: Certain commands, like a restore of a collection, might not complete properly if performed *during* an upgrade. They may need to be re-attempted after.
~ David On Mon, Oct 9, 2023 at 5:57 PM Houston Putman <hous...@apache.org> wrote: > 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 > > >
