The alias applies to the entire cloud, not a single core. So you'd have your indexing application point to a "collection alias" named 'index'. And that alias would point to core1. You'd have your query applications point to a "collection alias" named 'query', and that would point to core1, as well.
Then use the Collection API to create core1new across the entire cloud. Then update the 'index' alias to point to core1new. Feed documents in, run warm-up scripts, run smoke tests, etc., etc. When you're ready, point the 'query' alias to core1new. You're now running completely on core1new, and can use the Collection API to delete core1 from the cloud. Or keep it around as a backup to which you can restore simply by changing 'query' alias. -----Original Message----- From: Christopher Gross [mailto:cogr...@gmail.com] Sent: Wednesday, October 16, 2013 7:05 AM To: solr-user Subject: Re: Switching indexes 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 > >