Re: Excessive logging 8.8.0

[Ishan Chattopadhyaya]

This should be fixed now in https://issues.apache.org/jira/browse/SOLR-15136.
Thanks Markus.

On Sat, Feb 6, 2021 at 7:33 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I think we should release a 8.8.1 with that fixed.
>
> On Fri, 5 Feb, 2021, 4:09 pm Markus Jelsma, 
> wrote:
>
>> Thanks!
>>
>> Op do 4 feb. 2021 om 20:04 schreef Chris Hostetter <
>> hossman_luc...@fucit.org
>> >:
>>
>> >
>> > FWIW: that log message was added to branch_8x by 3c02c9197376 as part of
>> > SOLR-15052 ... it's based on master commit 8505d4d416fd -- but that does
>> > not add that same logging message ... so it definitely smells like a
>> > mistake to me that 8x would add this INFO level log message that master
>> > doesn't have.
>> >
>> > it's worth noting that 3c02c9197376 included many other "log.info(...)"
>> > messages that had 'nocommit' comments to change them to debug later ...
>> > making me more confident this is a mistake...
>> >
>> > https://issues.apache.org/jira/browse/SOLR-15136
>> >
>> >
>> > : Date: Thu, 4 Feb 2021 12:45:16 +0100
>> > : From: Markus Jelsma 
>> > : Reply-To: solr-user@lucene.apache.org
>> > : To: solr-user@lucene.apache.org
>> > : Subject: Excessive logging 8.8.0
>> > :
>> > : Hello all,
>> > :
>> > : We upgraded some nodes to 8.8.0 and notice there is excessive logging
>> on
>> > : INFO when some traffic/indexing is going on:
>> > :
>> > : 2021-02-04 11:42:48.535 INFO  (qtp261748192-268) [c:data s:shard2
>> > : r:core_node4 x:data_shard2_replica_t2] o.a.s.c.c.ZkStateReader already
>> > : watching , added to s
>> > : tateWatchers
>> > :
>> > : Is this to be expected?
>> > :
>> > : Thanks,
>> > : Markus
>> > :
>> >
>> > -Hoss
>> > http://www.lucidworks.com/
>> >
>>
>

Re: Collection Creation across DC

[Dominique Bejean]

Hi,

Sorry, it is in French, but here is my suggestion in order to replace the
deprecated CDCR and achieve HA
https://www.eolya.fr/2020/11/16/solrcloud-disaster-recovery-alternative-a-cdcr/

In short, each shard has one PULL replica on remote datacenter and these
PULL replicas are excluded from search by using shard.preference query
parameter.

Regards

Dominique



Le mer. 10 févr. 2021 à 22:05, Revas  a écrit :

> Hello,
>
> Can we create a collection across data Center ( shard replica is in a
> different data center)
> for HA ?
>
> Thanks
> Revas
>

Re: Down Replica is elected as Leader (solr v8.7.0)

[Rahul Goswami]

I haven’t delved into the exact reason for this, but what generally helps
to avoid this situation in a cluster is
i) During shutdown (in case you need to restart the cluster), let the
overseer node be the last one to shut down.
ii) While restarting, let the Overseer node be the first one to start
iii) Wait for 5-10 seconds between each subsequent node start

Hope this helps.

Best,
Rahul


On Thu, Feb 11, 2021 at 12:03 PM mmb1234  wrote:

> Hello,
>
> On reboot of one of the solr nodes in the cluster, we often see a
> collection's shards with
> 1. LEADER replica in DOWN state, and/or
> 2. shard with no LEADER
>
> Output from /solr/admin/collections?action=CLUSTERSTATUS is below.
>
> Even after 5 to 10 minutes, the collection often does not recover. Unclear
> why this is happening and what we can try to prevent or remedy it.
>
> ps: perReplicaState= true in solr v8.8.0 didn't work well because after a
> rebalance all replicas somehow get a "leader:true" status even though
> states.json looked ok.
>
> {
>   "responseHeader": {
> "status": 0,
> "QTime": 2
>   },
>   "cluster": {
> "collections": {
>   "datacore": {
> "pullReplicas": "0",
> "replicationFactor": "0",
> "shards": {
>   "__": {
> "range": null,
> "state": "active",
> "replicas": {
>   "core_node1": {
> "core": "datacore____replica_t187",
> "base_url": "http://solr-0.solr-headless:8983/solr;,
> "node_name": "solr-0.solr-headless:8983_solr",
> "state": "down",
> "type": "TLOG",
> "force_set_state": "false",
> "property.preferredleader": "true",
> "leader": "true"
>   },
>   "core_node2": {
> "core": "datacore____replica_t188",
> "base_url": "http://solr-1.solr-headless:8983/solr;,
> "node_name": "solr-1.solr-headless:8983_solr",
> "state": "active",
> "type": "TLOG",
> "force_set_state": "false"
>   },
>   "core_node3": {
> "core": "datacore____replica_t189",
> "base_url": "http://solr-2.solr-headless:8983/solr;,
> "node_name": "solr-2.solr-headless:8983_solr",
> "state": "active",
> "type": "TLOG",
> "force_set_state": "false"
>   }
> }
>   },
>   "__j": {
> "range": null,
> "state": "active",
> "replicas": {
>   "core_node19": {
> "core": "datacore___j_replica_t187",
> "base_url": "http://solr-0.solr-headless:8983/solr;,
> "node_name": "solr-0.solr-headless:8983_solr",
> "state": "down",
> "type": "TLOG",
> "force_set_state": "false",
> "property.preferredleader": "true"
>   },
>   "core_node20": {
> "core": "datacore___j_replica_t188",
> "base_url": "http://solr-1.solr-headless:8983/solr;,
> "node_name": "solr-1.solr-headless:8983_solr",
> "state": "active",
> "type": "TLOG",
> "force_set_state": "false"
>   },
>   "core_node21": {
> "core": "datacore___j_replica_t189",
> "base_url": "http://solr-2.solr-headless:8983/solr;,
> "node_name": "solr-2.solr-headless:8983_solr",
> "state": "active",
> "type": "TLOG",
> "force_set_state": "false"
>   }
> }
>   },
>   "__": {
> "range": null,
> "state": "active",
> "replicas": {
>   "core_node4": {
> "core": "datacore____replica_t91",
> "base_url": "http://solr-0...
>
>
>
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>

Sv: [SPAM] Process copyField only when field is absent in update

[Hullegård , Jimi]

I had a similar need in an old solr project. I was able to handle it with this 
configuration in solrconfig.xml:




lastModified
realLastModified


realLastModified






The logic is basically: Copy the default value (lastModified here) into the 
target field (realLastModified). If the target field has a value from earlier, 
then the FirstFieldValueUpdateProcessorFactory will remove the default value 
and the specified value is used. If no value was specified, then the default 
value is the only value there, and it remains there.

Note that this configuration comes from an old solr project, so there might be 
a more modern way to configure this. But the essence of this solution should 
still work fine.

/Jimi

ufuk yılmaz wrote:
>
> When I have a copyfield directive like,
>
>   
> And I send a document containing field named “b”, Solr tries to write 2 
> values into “b” field (one from the incoming doc and one from the copyfield)
> and gives error because “b” is not a multi valued field.
>
> Is it possible to activate copyField directive only when dest field is absent 
> from the incoming document?
>
Svenskt Näringsliv är företagsamhetens röst i Sverige. Vi samverkar med 50 
arbetsgivar- och branschorganisationer och är den gemensamma rösten för 60 000 
företag med nästan 2 miljoner medarbetare. Vår uppgift är att tala för alla 
företag och branscher, även de som ännu inte finns men som kan uppstå om 
förutsättningarna är de rätta. Ett bättre företagsklimat för ett bättre 
Sverige. Det är vårt uppdrag.

Svenskt Näringsliv behandlar dina personuppgifter i enlighet med GDPR. Här kan 
du läsa mer om vår behandling och dina rättigheter, 
Integritetspolicy

Solr wiki page update

[Vincent Brehin]

Hi community members,
I work for Adelean  https://www.adelean.com/ , we are offering services
around everything Search related, and especially Solr consulting and
support. We are based in Paris and operate mainly in France.
Is it possible to list our company on the support page (Support - SOLR -
Apache Software Foundation
) ?
Or give me the permission to edit it on confluence (my user:
vincent.brehin) ?
Thanks !
Best Regards,

Vincent

Process copyField only when field is absent in update

[ufuk yılmaz]

When I have a copyfield directive like,

Re: Using multiple language stop words in Solr Core

[Markus Jelsma]

Hell Abhay,

Do not enable stopwords unless you absolutely know what you are doing. In
general, it is a bad practice that somehow still lingers on.

But to answer the question, you must have one field and fieldType for each
language, so language specific filters go there. Also, using edismax and
multi-language search using mm (minimum should match) with stopwords
enabled spells trouble.

Set up per language fieldTypes without stopwords.

Regards,
Markus

Op do 11 feb. 2021 om 12:44 schreef Abhay Kumar <
abhay.ku...@anjusoftware.com>:

> Hello Team,
>
>
>
> Solr provides some data type out of box in managed schema for different
> languages such as english, french, japanies etc.
>
>
>
> We are using common data type "text_general" for fields declaration and
> using stopwards.txt for stopword filtering.
>
>
>
>  autoGeneratePhraseQueries="true" positionIncrementGap="100"
> multiValued="true">
>
> 
>
>   
>
>ignoreCase="true"/>
>
>   
>
>minGramSize="1"/>
>
> 
>
> 
>
>   
>
>ignoreCase="true"/>
>
>ignoreCase="true" synonyms="synonyms.txt"/>
>
>   
>
> 
>
>   
>
>
>
> While syncing data to Solr core we are importing different languages text
> in the fields such as french, english, german etc.
>
>
>
> My query is shall we use all different language stopwords into same
> "stopwards.txt" file or how solr use different language stopwords?
>
>
>
>
>
>
>
> *Warm Regards,*
>
>
>
> *Abhay Kumar* | Lead Developer
>
> 401/402, Pride Portal, Shivaji Housing Society, Off. S. B. Road | Shivaji
> Nagar, Pune-411 016
> +91 20 2563 1011 | Mobile: +91 9096644108
> anjusoftware.com
>
> 
> 
> 
> 
>
>
>
>
>
>
>
> *Confidentiality Notice  This email message, including
> any attachments, is for the sole use of the intended recipient and may
> contain confidential and privileged information. Any unauthorized view,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message. Anju Software, Inc. 4500 S. Lakeshore Drive, Suite
> 620, Tempe, AZ USA 85282.*
>

Using multiple language stop words in Solr Core

[Abhay Kumar]

Hello Team,

Solr provides some data type out of box in managed schema for different 
languages such as english, french, japanies etc.

We are using common data type "text_general" for fields declaration and using 
stopwards.txt for stopword filtering.



  
  
  
  


  
  
  
  

  

While syncing data to Solr core we are importing different languages text in 
the fields such as french, english, german etc.

My query is shall we use all different language stopwords into same 
"stopwards.txt" file or how solr use different language stopwords?



Warm Regards,

Abhay Kumar | Lead Developer
401/402, Pride Portal, Shivaji Housing Society, Off. S. B. Road | Shivaji 
Nagar, Pune-411 016
+91 20 2563 1011 | Mobile: +91 9096644108
anjusoftware.com
[cid:image001.png@01D70099.4ACD8C20][cid:image002.png@01D70099.4ACD8C20][cid:image003.png@01D70099.4ACD8C20][cid:image004.png@01D70099.4ACD8C20]



Confidentiality Notice

This email message, including any attachments, is for the sole use of the 
intended recipient and may contain confidential and privileged information. Any 
unauthorized view, use, disclosure or distribution is prohibited. If you are 
not the intended recipient, please contact the sender by reply email and 
destroy all copies of the original message. Anju Software, Inc. 4500 S. 
Lakeshore Drive, Suite 620, Tempe, AZ USA 85282.

Re: UPDATE collection's Rule-based Replica Placement

[Aroop Ganguly]

Moshe

An indirect way to do this could be to take backup of this collection and then 
restore with the desired placement rules.

Backup: 
Example: curl “https://solr.foo.com/solr/admin/collections? 
action=backup=backup_name=source_collection=hdfsBackupRepository=b1
 

Ref: 
https://lucene.apache.org/solr/guide/8_8/collection-management.html#backup 



Restore with rules:

Example: curl  
“https://solr.foo.com/solr/admin/collections?action=RESTORE=backup_name=targetcollection=hdfsBackupRepository=restore-demo=3=3=shard:*,replica:
 

   
<2,node:*=replica:*,cores:<3~=sysprop.PLATFORM_RACK:*,replica:<3”

Ref: 
https://lucene.apache.org/solr/guide/8_8/collection-management.html#restore 



Hope this helps and gives u a way forward.

Thanks
Aroop


> On Feb 10, 2021, at 2:23 PM, Ilan Ginzburg  wrote:
> 
> Do you look for something that would move existing collection replicas
> to comply with a new set of rules?
> I'm afraid that doesn't exist, but you can use the Collection API to
> move replicas "manually".
> 
> Ilan
> 
> On Tue, Feb 9, 2021 at 1:10 PM mosheB  wrote:
>> 
>> Hi community,
>> Using Solr 8.3, is there any way to change the replica placment of "running"
>> collection say "from this point forward" or should I recreate the collection
>> and migrate all my data from the existing collection to the new one?
>> Tried to use the COLLECTIONPROP action which doesn't do the job, instead it
>> just update collectionprops.json file and not really affect the replica
>> placement enforcement.
>> 
>> Thanks!
>> 
>> 
>> 
>> --
>> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html