On 1/3/13 2:50 AM, Mark Miller wrote:
Unfortunately, for 4.0, the collections API was pretty bare bones. You don't
actually get back responses currently - you just pass off the create command to
zk for the Overseer to pick up and execute.
So you actually have to check the logs of the Overseer to see what the problem
may be. I'm working on making sure we address this for 4.1.
If you look at the admin UI, in the zk tree, you should be able to see what
node is the overseer (look for its election node). The logs for that node
should indicate the problem.
FYI, if I remember right, replication factor is not currently optional.
Actually I believe it is.
In the future, I'd like it so you can say like replicationFactor=max_int, and
the overseer will periodically try to match that given the nodes it sees - but
we don't have that yet.
Uhhhh, but why!
It would be nice if you can say replicationFactor=X where X is higher
than your current number of nodes, and overseer then periodically tries
to see if it can honor your original request for replicationFactor X (it
will be when you eventually have X nodes in your cluster).
But specifying a MAX_INT value is IMHO a bad idea. It requires double
"resource"-usage to maintain double number of replica, so you dont want
more replica than necessary relative to your risk/HA-profile. I couldnt
imaging a setup where you want replica of each shard across all nodes no
matter how many nodes you add to your cluster. Of course you can always
give a replicationFactor of 10 (or something high) and then if you know
(currently believe) that you will never add more than 10 nodes to your
cluster, then basically you will achieve what you wanted to do with
MAX_INT. But if things evolve and you end up having 20 or 100 nodes in
you cluster you probably do not want more than 10 replica anyway.
When you add new nodes, to add them to a current collection you will either
have to use CoreAdmin API or pre configure the cores in solr.xml. All you need
is to specify a matching collection name for the new core.
- Mark
