bq: (collections API won't work because i use compositeId routing mode)
This had better NOT be true or SolrCloud is horribly broken. compositeId is
the default and it's tested a all the time by unit tests. So is implicit for
that matter.
One question I have is that you've specified a route field with this param:
router.field=mail_id
so the data is being routed based on a hash of that field, your GUID-based
id field is totally ignored for routing purposes. That may be what you intend,
but it's confusing that you mentioned the GUID in that context.
As far as Solr is concerned, you only have a 2 shard system on node1 I think.
There's some legacy code in Solr that tries to add cores back into a collection
when it thinks it sees an orphan, perhaps that's being triggered (incorrectly)
by the presence of the cores on node2 you're creating with the cores admin API.
Under any circumstances, here's what I recommend:
1> wipe out your current collection, Zookeeper's data too
2> You should be able to simply create your collection with both
nodes up with the appropriate replcationFactor etc.
3> Post any errors you get from using the Collections API and
we'll figure out what's up
4> Do not use the Core Admin API to try to add replicas to a SolrCloud
collection. Really. Under the covers, Solr cloud actually _does_
use the core admin API to create rplicase, but as you're seeing it
must be used exactly correctly to give the desired results.
5> You should _not_ have to put any files anywhere on the nodes
to create replicas....
Best,
Erick
On Fri, Mar 25, 2016 at 10:05 AM, Victor D'agostino
<victor.d.agost...@fiducial.net> wrote:
> Hi guys
>
> I am trying to set up a Solr Cloud environment of two Solr 5.4.1 nodes but
> the data are always indexed on the first node although the unique id is a
> GUID.
>
> It looks like I can't add an additional node. Could you tell me where i'm
> wrong ?
>
> I try to set up a collection named "db" with two shards on each node.
> Without replica. The config is named "copiemail3".
>
>
> On node n°1 I put schema.xml, solrconfig.xml, etc. in
> $SOLRHOME/configsets/copiemail3/conf/
> Then i do a upconfig to zkp1 with zkcli.sh
> I start Solr and create my collection with the API.
> wget --no-proxy
> "http://$HOSTNAME:8983/solr/admin/collections?numShards=2&collection.configName=copiemail3&route.name=compositeId&maxShardsPerNode=2&router.field=mail_id&name=db&replicationFactor=1&action=CREATE";
> My two first shards are created, Cloud is enabled and i also enable ping
> with the API :
> wget --no-proxy
> "http://$HOSTNAME:8983/solr/db_shard1_replica1/admin/ping?action=enable";
> wget --no-proxy
> "http://$HOSTNAME:8983/solr/db_shard2_replica1/admin/ping?action=enable";
> Finally I restart Solr
>
> On node n°2
> I start Solr and create the two shards with the cores API (collections API
> won't work because i use compositeId routing mode) :
> wget --no-proxy
> "http://$HOSTNAME:8983/solr/admin/cores?action=CREATE&schema=schema.xml&shard=shard3&instanceDir=db_shard3_replica1&indexInfo=false&name=db_shard3_replica1&config=solrconfig.xml&collection=db&dataDir=data";
> wget --no-proxy
> "http://$HOSTNAME:8983/solr/admin/cores?action=CREATE&schema=schema.xml&shard=shard4&instanceDir=db_shard4_replica1&indexInfo=false&name=db_shard4_replica1&config=solrconfig.xml&collection=db&dataDir=data";
> Like node 1 i activate the ping and restart Solr.
>
> On each Solr admin interface I can see ZooKeeper config is good (4 alived
> nodes). Cloud schema seems ok because i have my db collection, 4 shards on
> two nodes (all leaders).
>
>
> Search request are well distributed but as I said before the data are always
> indexed on the two shards on the first node :
>
>
>
> [root@node1 ~]# /data/solr-5.4.1/bin/solr healthcheck -c db -z
> localhost:2181
> {
> "collection":"db",
> "status":"healthy",
> "numDocs":10000,
> "numShards":4,
> "shards":[
> {
> "shard":"shard1",
> "status":"healthy",
> "replicas":[{
> "name":"core_node2",
> "url":"http://10.69.220.46:8983/solr/db_shard1_replica1/";,
> "numDocs":5175,
> "status":"active",
> "uptime":"0 days, 0 hours, 14 minutes, 35 seconds",
> "memory":"339.3 MB (%14.1) of 2.4 GB",
> "leader":true}]},
> {
> "shard":"shard2",
> "status":"healthy",
> "replicas":[{
> "name":"core_node1",
> "url":"http://10.69.220.46:8983/solr/db_shard2_replica1/";,
> "numDocs":4825,
> "status":"active",
> "uptime":"0 days, 0 hours, 14 minutes, 35 seconds",
> "memory":"339.3 MB (%14.1) of 2.4 GB",
> "leader":true}]},
> {
> "shard":"shard3",
> "status":"healthy",
> "replicas":[{
> "name":"core_node3",
> "url":"http://10.69.220.47:8983/solr/db_shard3_replica1/";,
> "numDocs":0,
> "status":"active",
> "uptime":"0 days, 0 hours, 13 minutes, 44 seconds",
> "memory":"177 MB (%7.4) of 2.4 GB",
> "leader":true}]},
> {
> "shard":"shard4",
> "status":"healthy",
> "replicas":[{
> "name":"core_node4",
> "url":"http://10.69.220.47:8983/solr/db_shard4_replica1/";,
> "numDocs":0,
> "status":"active",
> "uptime":"0 days, 0 hours, 13 minutes, 44 seconds",
> "memory":"177 MB (%7.4) of 2.4 GB",
> "leader":true}]}]}
>
>
> Thanks for your help
>
> Victor
>
>
>
> ________________
> Ce message et les éventuels documents joints peuvent contenir des
> informations confidentielles. Au cas où il ne vous serait pas destiné, nous
> vous remercions de bien vouloir le supprimer et en aviser immédiatement
> l'expéditeur. Toute utilisation de ce message non conforme à sa destination,
> toute diffusion ou publication, totale ou partielle et quel qu'en soit le
> moyen est formellement interdite. Les communications sur internet n'étant
> pas sécurisées, l'intégrité de ce message n'est pas assurée et la société
> émettrice ne peut être tenue pour responsable de son contenu.
