I used it back in the days when you could migrate from v3->4->5->6. It solved the issue that Solr 6 could only read a Lucene 6 or Lucene 5 index, but after the sequence of upgrades you'd get there. I even wrote a wrapper to automate it all at https://github.com/cominvent/solr-tools/tree/master/upgradeindex
However, now that Lucene 9 refuses to work with any index created before Lucene 8, I agree with Jason that I cannot see any utility for the upgrade tool anymore. Since, if you have a Solr 6 index, it won't work in Solr 9 even if you used the upgrader. And if you already have a Lucene 8 index, no need to upgrade by hand, just start Solr 9 on top of the Lucene 8 index and it will be upgraded. +1 to remove mention from ref-guide. PS: If the upgrader tool was able to patch the original-index-version from the binary index (and user understands the risks), then there could be some utility. But I'm not aware of such an option. Jan > 3. juni 2024 kl. 21:20 skrev Gus Heck <gus.h...@gmail.com>: > > I've fielded many questions on this from clients. Folks who have managed > databases expect to be able to upgrade the data serially across versions > and such, so these questions come up alot with organizations early in their > journey with search. Essentially, I tell them that it's a stop gap tool for > use if there's a serious security issue and you really need to move up one > version to get away from the security issue, but otherwise the correct > procedure is to re-index. (And this is sometimes when I find out if they've > really planned for reindexing or not). A down-side of the existence of this > tool is that its presence in the ref guide allows people to prolong the > period where they confuse managing a search index with managing a database. > That said, I think it may have a place to help folks who got going without > knowing enough about search engines to extend the period they have to dig > themselves out of bad situations (by allowing an upgrade while they figure > out how they are going to handle re-indexing more data than they previously > planned on indexing all at once). So far every one of my clients has taken > my advice and simply re-indexed (though not always without grumbling!), so > I have to admit I've not actually seen it used, but in theory it makes some > sense. > > -Gus > > On Mon, Jun 3, 2024 at 2:20 PM David Smiley <dsmi...@apache.org> wrote: > >> FWIW, in my experience I've never run this tool (nor colleagues) at >> any stage in my career that I can remember. For one reason, all the >> systems could re-index if they needed to. >> It may be best to remove this information, as it could introduce more >> confusion than it helps. >> >> On Mon, Jun 3, 2024 at 1:34 PM Jason Gerlowski <gerlowsk...@gmail.com> >> wrote: >>> >>> Hey all, >>> >>> I was poking around the ref-guide a bit recently and noticed our page >>> on the "IndexUpgraderTool" that Lucene produces. [1] >>> >>> AFAICT, the page doesn't hint at when/why a user might want to use the >>> IndexUpgraderTool. Maybe at one point the tool might've been >>> preferred to loading the index in an upgraded Solr version, but I >>> haven't heard of anyone doing that in the last few years. >>> >>> Is this something we expect users to still do? If so, for what >>> usecase? And if not - should we drop it from the ref-guide - it seems >>> like it might confuse folks since it's not actually needed to upgrade >>> Solr versions... >>> >>> Best, >>> >>> Jason >>> >>> [1] >> https://solr.apache.org/guide/solr/latest/deployment-guide/indexupgrader-tool.html >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book)
