Hi/Bok Jakov, 2) sounds good to me. It means no down-time. 1) means stoppage. If stoppage is not OK, but falling behind with indexing new content is OK, you could: * add a new cluster * start reading from old index and indexing into the new index * stop old cluster when done * index new content to new cluster (or maybe you can be doing this all along if indexing old + new at the same time is OK for you)
Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/ On Wed, Oct 29, 2014 at 10:18 PM, Jakov Sosic <jso...@gmail.com> wrote: > Hi guys > > > I was wondering is there some smart way to migrate Solr cloud from 1 set > of machines to another? > > Specificaly, I have 2 cores, each of them with 2 replicas and 2 shards, > spread across 4 machines. > > We bought new HW and are in a process of moving to new 4 machines. > > > What are my options? > > > 1) - Create new cluster on new set of machines. > - stop write operations > - copy data directories from old machines to new machines > - start solrs on new machines > > > 2) - expand number of replicas from 2 to 4 > - add new solr nodes to cloud > - wait for resync > - stop old solr nodes > - shrink number of replicas from 4 back to 2 > > > Is there any other path to achieve this? > > I'm leaning towards no1, because I don't feel too comfortable with doing > all those changes explained in no2 ... > > Ideas? >
