Re: Odd Solr zkcli script behavior

2020-08-27 Thread Dominique Bejean
Hi,

You can also connect to ZK element and use zkCli.sh tools

http://www.mtitek.com/tutorials/zookeeper/zkCli.php

Regards

Dominique


Le jeu. 27 août 2020 à 17:28, Webster Homer <
webster.ho...@milliporesigma.com> a écrit :

> I am using solr 7.7.2 solr cloud
>
> We version our collection and config set names with dates. I have two
> collections sial-catalog-product-20200711 and
> sial-catalog-product-20200808. A developer uploaded a configuration file to
> the 20200711 version that was not checked into our source control, and I
> wanted to retrieve is from zookeeper as we cannot find the version anywhere
> else. So I tried the zkcli.sh shell script.
>
> It always throws an exception when trying to access
> sial-catalog-product-20200711 but not when trying to access
> sial-catalog-product-20200808
> INFO  - 2020-08-27 10:26:36.283;
> org.apache.solr.common.cloud.ConnectionManager; zkClient has connected
> Exception in thread "main"
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /solr/configs/sial-catalog-product-20200711/_schema_model-store.json
>   at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:114)
>   at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
>   at
> org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1221)
>   at
> org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:358)
>   at
> org.apache.solr.common.cloud.SolrZkClient$$Lambda$6/1384010761.execute(Unknown
> Source)
>   at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)
>   at
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:358)
>   at org.apache.solr.cloud.ZkCLI.main(ZkCLI.java:331)
>
> I can see both collections and configsets in the SolrAdmin console. I can
> download the file from sial-catalog-product-20200808 with no problem. As
> far as I can tell the two config sets are accessible in the cloud, both
> config sets and collections are available the only difference is that we
> have an alias set to point to the newer one which is current, but the zkcli
> script does not use the alias.
>
> I tried both the getfile and downconfig commands and the behavior is
> consistent I can always get to the later one but the 20200711 version gives
> the NoNodeException
> What is going on here?
>
> A general comment, we use Zookeeper chroot, but the zkcli command doesn't
> seem to care if I pass the root on the zkhost argument or not. I also
> noticed that the zkcli command is poorly documented.
>
>
>
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient,
> you must not copy this message or attachment or disclose the contents to
> any other person. If you have received this transmission in error, please
> notify the sender immediately and delete the message and any attachment
> from your system. Merck KGaA, Darmstadt, Germany and any of its
> subsidiaries do not accept liability for any omissions or errors in this
> message which may arise as a result of E-Mail-transmission or for damages
> resulting from any unauthorized changes of the content of this message and
> any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its
> subsidiaries do not guarantee that this message is free of viruses and does
> not accept liability for any damages caused by any virus transmitted
> therewith.
>
>
>
> Click http://www.merckgroup.com/disclaimer to access the German, French,
> Spanish and Portuguese versions of this disclaimer.
>


RE: Odd Solr zkcli script behavior

2020-08-27 Thread Webster Homer
Never mind I figured out my problem.

-Original Message-
From: Webster Homer 
Sent: Thursday, August 27, 2020 10:29 AM
To: solr-user@lucene.apache.org
Subject: Odd Solr zkcli script behavior

I am using solr 7.7.2 solr cloud

We version our collection and config set names with dates. I have two 
collections sial-catalog-product-20200711 and sial-catalog-product-20200808. A 
developer uploaded a configuration file to the 20200711 version that was not 
checked into our source control, and I wanted to retrieve is from zookeeper as 
we cannot find the version anywhere else. So I tried the zkcli.sh shell script.

It always throws an exception when trying to access 
sial-catalog-product-20200711 but not when trying to access 
sial-catalog-product-20200808 INFO  - 2020-08-27 10:26:36.283; 
org.apache.solr.common.cloud.ConnectionManager; zkClient has connected 
Exception in thread "main" 
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode 
for /solr/configs/sial-catalog-product-20200711/_schema_model-store.json
  at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:114)
  at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
  at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1221)
  at 
org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:358)
  at 
org.apache.solr.common.cloud.SolrZkClient$$Lambda$6/1384010761.execute(Unknown 
Source)
  at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)
  at 
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:358)
  at org.apache.solr.cloud.ZkCLI.main(ZkCLI.java:331)

I can see both collections and configsets in the SolrAdmin console. I can 
download the file from sial-catalog-product-20200808 with no problem. As far as 
I can tell the two config sets are accessible in the cloud, both config sets 
and collections are available the only difference is that we have an alias set 
to point to the newer one which is current, but the zkcli script does not use 
the alias.

I tried both the getfile and downconfig commands and the behavior is consistent 
I can always get to the later one but the 20200711 version gives the 
NoNodeException What is going on here?

A general comment, we use Zookeeper chroot, but the zkcli command doesn't seem 
to care if I pass the root on the zkhost argument or not. I also noticed that 
the zkcli command is poorly documented.



This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, you 
must not copy this message or attachment or disclose the contents to any other 
person. If you have received this transmission in error, please notify the 
sender immediately and delete the message and any attachment from your system. 
Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept 
liability for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any unauthorized 
changes of the content of this message and any attachment thereto. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not guarantee that this 
message is free of viruses and does not accept liability for any damages caused 
by any virus transmitted therewith.



Click http://www.merckgroup.com/disclaimer to access the German, French, 
Spanish and Portuguese versions of this disclaimer.