Shawn, It all makes sense, I'm just dealing with production servers here so I'm trying to be very careful (shutting down one node at a time is OK, just don't want to do something catastrophic.)
OK, so I should use that aliasing feature. On index1 I have: core1 core1new core2 On index2 and index3 I have: core1 core2 If I do the "alias" command on index1 and have "core1" alias "core1new": 1) Will that then get rid of the existing core1 and have "core1new" data be used for queries? 2) Will that change make core1 instances on index2 and index3 update to have "core1new" data? Thanks again! -- Chris On Tue, Oct 15, 2013 at 7:30 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 10/15/2013 2:17 PM, Christopher Gross wrote: > >> I have 3 Solr nodes (and 5 ZK nodes). >> >> For #1, would I have to do that on all of them? >> For #2, I'm not getting the auto-replication between node 1 and nodes 2 & >> 3 >> for my new index. >> >> I have 2 indexes -- just call them "index" and "indexbk" (bk being the >> backup containing the full data set) up and running on one node. >> If I were to do a swap (via the Core Admin page), would that push the >> changes for indexbk over to the other two nodes? Would I need to do that >> switch on the leader, or could that be done on one of the other nodes? >> > > For #1, I don't know how you want to handle your sharding and/or > replication. I would assume that you probably have numShards=1 and > replicationFactor=3, but I could be wrong. At any rate, where the > collection lives is an implementation detail that's up to you. SolrCloud > keeps track of all your collections, whether they are on one server or all > servers. Typically you can send requests (queries, API calls, etc) that > deal with entire collections to any node in your cluster and they will be > handled correctly. If you need to deal with a specific core, that call > needs to go to the correct node. > > For #2, when you create a core and want it to be a replica of something > that already exists, you need to give it a name that's not in use on your > cluster, such as index2_shard1_replica3. You also tell it what collection > it's part of, which for my example, would probably be index2. Then you > tell it what shard it will contain. That will be shard1, shard2, etc. > Here's an example of a CREATE call: > > http://server:port/solr/admin/**cores?action=CREATE&name=** > index2_shard1_replica3&**collection=index2&shard=shard1 > > For the rest of your message: Core swapping and SolrCloud do NOT get > along. If you are using SolrCloud, CoreAdmin features like that need to > disappear from your toolset. Attempting a core swap will make bad things > (tm) happen. > > Collection aliasing is the way in SolrCloud that you can now do what used > to be done with swapping. You have collections named index1, index2, > index3, etc ... and you keep an alias called just "index" that points to > one of those other collections, so that you don't have to change your > application - you just repoint the alias and all the application queries > going to "index" will go to the correct place. > > I hope I haven't made things more confusing for you! > > Thanks, > Shawn > >
