Bringing this thread back from the grave! Looks like the approach won't fly. I would really like to know the reason for blocking index upgrade for any index ever touched by 6.x. Reindexing the whole data is not a practical approach for scenarios when there are multiple client deployments and would result in the user getting blocked for possibly several days (aka multiple deployments impacted). This is particularly the case with large indexes (hundreds of GBs, and in some cases > 1 TB). Consequently, we are stuck on Solr 7.x. As mentioned earlier, running optimize with maxSegments=1 won't help either, and I can't seem to fathom why?
What is the reason for blocking the upgrade ? If someone has been able to successfully upgrade an index written in 6.x in the past to 8.x without doing a full reindex, I would love to get some ideas. Thanks, Rahul On Thu, Oct 7, 2021 at 9:47 AM Rahul Goswami <rahul196...@gmail.com> wrote: > That’s what we are planning on doing. Block writes(making index > read-only), write into a parallel directory using 8.x lucene codec and then > switch over if/when completely written. Downside is (temporarily) requiring > double the index size in total disk space while writing the index given > that we regularly run into multi-terabyte indexes. > > Easier said than done, given the unknown challenges in doing so, so the > feasibility remains to be seen. I really wish there was a supported way to > do this out of the box. > > On Thu, Oct 7, 2021 at 9:36 AM Michael Conrad <mich...@newsrx.com> wrote: > >> >> >> On 10/7/21 8:46 AM, Rahul Goswami wrote: >> > Won’t work. I have tried optimize on 7.7.2 to 8.x where several segments >> > were originally written in 5.x and 6.x. >> > We are scratching our heads to achieve this seamlessly since reindexing >> > will take several weeks given the size of indexes for many of our >> customers. >> > >> > -Rahul >> > >> > >> >> There really needs to be a way to simply rewrite existing segments into >> the new lucene format. with appropriate errors in case of unsupported >> field types, etc. >> >
