I'd suggest using the Collections API: http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=alias&collections=collection1,collection2...
See the Collections Aliases section of http://wiki.apache.org/solr/SolrCloud. BTW, once you make the aliases, Zookeeper will have entries in /aliases.json that will tell you what aliases are defined and what they point to. -----Original Message----- From: Christopher Gross [mailto:cogr...@gmail.com] Sent: Wednesday, October 16, 2013 10:44 AM To: solr-user Subject: Re: Switching indexes Garth, I think I get what you're saying, but I want to make sure. I have 3 servers (index1, index2, index3), with Solr living on port 8080. Each of those has 3 cores loaded with data: core1 (old version) core1new (new version) core2 (unrelated to core1) If I wanted to make it so that queries to core1 are really going to core1new, I'd run: http://index1:8080/solr/admin/cores?action=CREATEALIAS&name=core1&collections=core1new&shard=shard1 Correct? -- Chris On Wed, Oct 16, 2013 at 9:02 AM, Garth Grimm < garthgr...@averyranchconsulting.com> wrote: > 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 > > > > >
