On 2/24/2018 3:13 AM, Marvin Bredal Lillehaug wrote:
We have a multicore Solr-instance that currently is running version
6.6.2.
For local development we run
./solr start -v -d $solrDir/server -h localhost -p $SOLR_PORT -c -f -s
$solrHomeDir -a "-Dbootstrap_conf=true -Djetty.host=localhost" -m 4096m
Are you aware that the -c option, without the -z option, will start an
embedded zookeeper server and put Solr into SolrCloud mode? The
embedded ZK server is not recommended except for setting up a proof of
concept. For production, the ZK ensemble needs at least three servers.
Setting jetty.host to localhost will make it so that Solr cannot be
accessed remotely, it will only work on the local machine. This defeats
one of the primary purposes of SolrCloud -- a highly available fault
tolerant cluster.
The bootstrap_conf setting is intended to be used precisely once -- in a
situation where you want to convert a non-cloud install to SolrCloud.
It is not meant to be defined every time you start Solr. I would
strongly recommended that you do not use bootstrap at all. Instead,
start up a new install, create your collection how you desire, and then
run your indexing so you create the index fresh.
On Solr 6 everything starts fine, and cores and collections are
created on startup.
When running the same setup on Solr 7.x.x it crash with Could not find
collection : nvdb-transactionlog when
running CoreContainer.repairCoreProperty. Logs for Solr 6 and 7 attached.
That error probably means that the collection was not found in the
ZooKeeper database. Are you doing any kind of configuration or changes
on the embedded ZK server before you start Solr? Does the user that's
running Solr have enough permissions to create and write to the ZK data
directory? The problem *might* be the bootstrap_conf setting, but I am
not sure whether that is correct. Unless something is very broken in
your install, then I would suspect the bootstrap option is causing a
problem.
Thanks,
Shawn