Well, a Solr index is just a bunch of files. So what I'd do is grab two machines that are lying around (or even just one with two Solrs) and try it.
You could just copy the whole Solr tree from your master to machine 1, from your slave to machine 2. You'd have to change solrconfig on machine 2 to point to machine1, but otherwise that's pretty much it. Now you can freely try it without endangering your production system. If the indexes are too big, just set up your test machines and index a few (say 10,000 docs) to each _then_ try the upgrade. Yeah, upgrading is always "interesting", I shudder every time I have to... Best, Erick On Wed, Jan 27, 2016 at 5:54 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 1/27/2016 2:00 AM, Zaccheo Bagnati wrote: >> I apologize for connecting to this thread but I'm interested in this topic >> as well. I think we have a similar configuration: solr 4.8, standard >> master/slave replication, data is indexed on master and then replicated to >> slave. I'm investigating how to migrate to solr 5.*. >> Erick, you say that there is a full backward compatibility between 4.* and >> 5.* so, for example, we could migrate the slave (and it will continue to >> read old indexes), then migrate the master (and it could could even update >> old indexes without need for full reindex). It seems too simple... and I >> hope it will be so, but my experience of migrations is not so painless as >> you say...(I'm not referring to SOLR) >> Is there anyone who tried this approach on a production environment? What I >> should be more careful of? Is there any incompatibility in REST calls and >> responses? > > Upgrading slaves first and then the master is the recommended way to do > upgrades in a master/slave installation. Many people have done upgrades > in this exact way with success. > > I personally would completely rebuild the index once I had the masters > upgraded, so Solr will perform best. > > Thanks, > Shawn >
