Re: Migrating cloud to another set of machines

2014-10-30 Thread Jakov Sosic

On 10/30/2014 04:47 AM, Otis Gospodnetic wrote:

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)
--


Thank you for suggestions Otis.

Everything is acceptable currently, but in the future as the data grows, 
we will certainly enter those edge cases where neither stopping indexing 
nor stopping queries will be acceptable.


What makes things a little bit more problematic is that ZooKeepers are 
migrating also to new machines.





Re: Migrating cloud to another set of machines

2014-10-30 Thread Otis Gospodnetic
I think ZK stuff may actually be easier to handle, no?
Add new ones to the existing ZK cluster and then remove the old ones.
Won't this work smoothly?

Otis
--
Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr  Elasticsearch Support * http://sematext.com/


On Thu, Oct 30, 2014 at 1:16 PM, Jakov Sosic jso...@gmail.com wrote:

 On 10/30/2014 04:47 AM, Otis Gospodnetic wrote:

 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)
 --


 Thank you for suggestions Otis.

 Everything is acceptable currently, but in the future as the data grows,
 we will certainly enter those edge cases where neither stopping indexing
 nor stopping queries will be acceptable.

 What makes things a little bit more problematic is that ZooKeepers are
 migrating also to new machines.





Re: Migrating cloud to another set of machines

2014-10-30 Thread Erick Erickson
Jakov:

Be particularly aware of the ADDREPLICA collections API
command here:
https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api_addreplica

That allows you to specify exactly which node the new replica should be on,
so you can force it to be on the new HW. Here's a guide:

http://heliosearch.org/solrcloud-assigning-nodes-machines/

Best,
Erick

On Thu, Oct 30, 2014 at 3:40 PM, Otis Gospodnetic
otis.gospodne...@gmail.com wrote:
 I think ZK stuff may actually be easier to handle, no?
 Add new ones to the existing ZK cluster and then remove the old ones.
 Won't this work smoothly?

 Otis
 --
 Monitoring * Alerting * Anomaly Detection * Centralized Log Management
 Solr  Elasticsearch Support * http://sematext.com/


 On Thu, Oct 30, 2014 at 1:16 PM, Jakov Sosic jso...@gmail.com wrote:

 On 10/30/2014 04:47 AM, Otis Gospodnetic wrote:

 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)
 --


 Thank you for suggestions Otis.

 Everything is acceptable currently, but in the future as the data grows,
 we will certainly enter those edge cases where neither stopping indexing
 nor stopping queries will be acceptable.

 What makes things a little bit more problematic is that ZooKeepers are
 migrating also to new machines.





Migrating cloud to another set of machines

2014-10-29 Thread Jakov Sosic

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?


Re: Migrating cloud to another set of machines

2014-10-29 Thread Otis Gospodnetic
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?