Renee - you have probably already thought of this, but just in case it helps... (It helped me a lot several years ago and I hadn't thought of it at the time...)
If you end up needing to do a big re-index, Production doesn't have to be affected (assuming you have the hardware/cloud resources). You can reindex into a non-production environment, test, and when all is well, just point load balancers at the new Solr environment. In this scenario your users would probably not even notice the change unless you tell them... Of course this does NOT in any way lessen the other stressors you've been discussing - and - as I said, you probably already thought of it... On Mon, Oct 10, 2016 at 10:18 AM, Renee Sun <renee_...@mcafee.com> wrote: > Shawn and Ari, > the 3rd party jars are exactly just one of the concerns I have. > We had more than just a multi-lingual integration, we have to integrate > with > many other 3rd party tools. We basically deploy all those jars into an > 'external' lib extension path in production, then for each 3rd party tools > involved, we have to follow their instruction to integrate with solr/tomcat > by symlink them into either tomcat/lib or ourwebapps/WEB-INF/lib etc. We > will need to rewrite these integration in the build process I imagine. > > I am sure there will be a lot of other work if we go for this 'upgrade' ... > I bet we will need to re-index the data ... for each major solr version > upgrade (like from 3.0 to 4.0) the data needs to be re-indexed and this is > another huge concern. > > Our data is not that BIG considering what others have nowadays, but still > few hundreds of terabytes are a pain in the neck to go through re-index > process, resource wise and time wise. Almost a road block. > > I have tested that solr shard query works with querying data from solr > servers with different versions, so we could upgrade our production solr > servers and reindex data on them one by one... but still, it is almost a > non-practical thing to do, similar to how Ari feels, I also would rather > not > upgrade ... > > I guess we fortunately started to use Solr long time ago (which benefited > our system of its key feature to search for email content in our SAAS > services), but on the other side we become so depending on the old version > of solr, as a reality with how Solr evolves, it is so hard for us to keep > up > with these upgrades... > > few years ago, the scalability become a major issue in our system, I did a > lot of experiments with the Solr 4.0, unfortunately by then the lack of > supporting of multi-tenancy as well as other fundamental flaws drove it out > of our choices, so our team ended up with developing a light weighted > scalalible layer wrapping up on top of solr, which worked very well but > here > we are... from all elements: build process, architect, data migration etc > .... it is scary. > > Good discussion and it is great help ... :-) > Renee > > > > -- > View this message in context: http://lucene.472066.n3. > nabble.com/solr-5-leaving-tomcat-will-I-be-the-only-one- > fearing-about-this-tp4300065p4300523.html > Sent from the Solr - User mailing list archive at Nabble.com. >
