Alias switching is a very good option for cloud users, and one of the
benefits of using cloud. OP is on "user managed" (also previously known as
"standalone" and then briefly as "legacy mode") so this is not available.
Order of preference:
1) build 100% new into new index (much better than the rest)
2) delete *:* with force merge
3) delete *:* without force merge (just tested on 8.8.2 cloud instance, and
this appears to delete segments properly in that case).
4) overwrite existing docs with new.
Only 1 ensures that you can fully upgrade to the latest lucene version and
take advantage of all new enhancements and features. { "delete": {
"query":"*:*"}}
2 through 4 will retain the old
- core.properties file,
- tlog files,
- a segments_N file.
The segments file is described here (check lucene docs for your specific
version of course):
https://lucene.apache.org/core/8_11_1/core/org/apache/lucene/index/SegmentInfos.html
... note the minLuceneVersion and header which specifies the codec are
retained. So anything but #1 leaves you with an older index that just
happens to have fresh docs. Fresh docs allow you to turn on new field
options etc safely, but 1 is clear and simple, the rest are more murky in
their final result and leave ghosts of the past to haunt you in odd ways
later.
Also with 2-4 you need to be thinking about your LUCENE_MATCH_VERSION
setting, see https://sease.io/2021/04/lucenematchversion-in-apache-solr.html
for some info on that
With 1 just use the latest (though setting an explicit value is better than
"LATEST" as noted in the link)
On Tue, Jun 14, 2022 at 8:36 AM Michael Conrad <mich...@newsrx.com> wrote:
> In my experience, you need to index to a new collection, then use the
> alias command to point the connection endpoint to the new collection.
> Not sure how this works in non-cloud mode.
>
> We've tried reindexing to an existing collection, but, the created
> LUCENE version stamp doesn't get updated, and even though the new
> segments in theory should be the new LUCENE version, we still could not
> go up to the next version. This was when going to 8. We had some indexes
> still marked as 6, even though we had fully reindexed to the same
> collection and optimized down to a single segment.
>
> On 6/12/22 14:21, Dave wrote:
> > You don’t need a new core/collection, just reindex everything again.
> Ideally since you’re using standalone (way better than cloud imo) you can
> use the same indexer, just do an integrity check after the fact to make
> sure the document counts are the same. You don’t really need to do that
> delete if you are just going to obliterate the previous install and index
> >
> >> On Jun 12, 2022, at 1:49 PM, Christopher Schultz<
> ch...@christopherschultz.net> wrote:
> >>
> >> All,
> >>
> >> We've been using the same major version of Solr for years so haven't
> had to do this yet, but we are preparing to upgrade between major versions,
> now.
> >>
> >> After upgrading, I'm assuming that the existing index is "usable" but
> I've read many times that "you should reindex after a major version change."
> >>
> >> Okay.
> >>
> >> Does that just mean:
> >>
> >> 1. delete *:*
> >> 2. re-add all documents
> >>
> >> ?
> >>
> >> Or do we have to create a new core/collection with the schema from
> scratch and load it?
> >>
> >> I'm using standalone Solr (i.e. no ZK) with a single core if that makes
> any difference.
> >>
> >> Thanks,
> >> -chris
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
