Thanks Shawn, the explanations help bring me forward to the "SolrCloud" mentality.
So it sounds like going forward that I should have a more complicated name (ex: coll1-20131015) aliased to coll1, to make it easier to switch in the future. Now, if I already have an index (copied from one location to another), it sounds like I should just remove my existing (bad/old data) coll1, create the "replicated" one (calling it coll1-<date>), then alias coll1 to that one. This type of information would have been awesome to know before I got started, but I can make do with what I've got going now. Thanks again! -- Chris On Wed, Oct 16, 2013 at 2:40 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 10/16/2013 11:51 AM, Christopher Gross wrote: > > Ok, so I think I was confusing the terminology (still in a 3.X mindset I > > guess.) > > > > From the Cloud->Tree, I do see that I have "collections" for what I was > > calling "core1", "core2", etc. > > > > So, to redo the above, > > Servers: index1, index2, index3 > > Collections: (on each) coll1, coll2 > > Collection (core?) on index1: coll1new > > > > Each Collection has 1 shard (too small to make sharding worthwhile). > > > > So should I run something like this: > > > http://index1:8080/solr/admin/collections?action=CREATEALIAS&name=coll1&collections=col11new > > > > Or will I need coll1new to be on each of the index1, index2 and index3 > > instances of Solr? > > I don't think you can create an alias if a collection already exists > with that name - so having a collection named core1 means you wouldn't > want an alias named core1. I could be wrong, but just to keep things > clean, I wouldn't recommend it, even if it's possible. > > That CREATEALIAS command will only work if coll1new shows up in > /collections and shows green on the cloud graph. If it does, and you're > using an alias name that doesn't already exist as a collection, then > you're good. > > Whether coll1new is living on one server, two servers, or all three > servers doesn't matter for CREATEALIAS, or for most other > collection-related topics. Any query or update can be sent to any > server in the cloud and it will be routed to the correct place according > to the clusterstate. > > Where things live and how many replicas there are *does* matter for a > discussion about redundancy. Generally speaking, you're going to want > your shards to have at least two replicas, so that if a Solr instance > goes down, or is taken down for maintenance, your cloud remains fully > operational. In your situation, you probably want three replicas - so > each collection lives on all three servers. > > So my general advice: > > Decide what name you want your application to use, make sure none of > your existing collections are using that name, and set up an alias with > that name pointing to whichever collection is current. Then change your > application configurations or code to point at the alias instead of > directly at the collection. > > When you want to do your reindex, first create a new collection using > the collections API. Index to that new collection. When it's ready to > go, use CREATEALIAS to update the alias, and your application will start > using the new index. > > Thanks, > Shawn > >
