maybe that is best left for the JIRA/dev list!
From: users@solr.apache.org At: 04/02/25 01:25:42 UTC-4:00To:
users@solr.apache.org
Subject: Re: Automatic upgrade of Solr indexes over multiple versions
This being an auxiliary process, for performance reasons, there is no
parallelism in the c
> > >
> > > In our case, we were considering developing a dual write system with
> > > a versionField defined to ensure consistent ordering between the two
> > > clouds, n and n+m, and having this live outside of Solr. Then, the
> > > actual backfill could be kick
> we enabled dual write. And then finally deleting the old cloud once
> > we routed traffic to the new one (and let it "bake"). As Gus points
> > out, at "big data" scale the backfill becomes hard and so the
> > idea of making this less resource intensive is en
gt; pagination and sending them to index 🤔 About being in-place, how can
> it
> > > work when a new Solr version requires a different schema or config
> file,
> > > because time to time old definitions don’t work in a new version.
> > >
> > > -ufuk
> > >
>
from some snapshot taken *after*
> we enabled dual write. And then finally deleting the old cloud once
> we routed traffic to the new one (and let it "bake"). As Gus points
> out, at "big data" scale the backfill becomes hard and so the
> idea of making this less res
s@solr.apache.org At: 03/30/25 14:59:16 UTC-4:00To:
users@solr.apache.org
Subject: Re: Automatic upgrade of Solr indexes over multiple versions
Some thoughts:
A lot depends on the use case for this sort of thing. In the case of
relatively small installs that can afford to run >2x disk and
Either way I am sure this would be a great addition to
> > the tool belt for getting people to finally move off
> > ancient versions of Solr.
> >
> > Look forward to discussing this more on the JIRA!
> >
> > Luke
> >
> > From: users@solr.apache.org
his more on the JIRA!
>
> Luke
>
> From: users@solr.apache.org At: 03/28/25 01:05:57 UTC-4:00To:
> users@solr.apache.org
> Subject: Automatic upgrade of Solr indexes over multiple versions
>
> Today upgrading from Solr version X to X+2 requires complete reingestion
Today upgrading from Solr version X to X+2 requires complete reingestion of
data from source. This comes from Lucene's constraint which only guarantees
index compatibility between the version the index was created in and the
immediate next version.
This reindexing usually comes with added downtim
