Having custom core.properties files is “fraught”. First of all, that file can be re-written. Second, the collections ADDREPLICA command will create a new core.properties file. Third, any mistakes you make when hand-editing the file can have grave consequences.
What change exactly do you want to make to core.properties and why? Trying to reproduce “what a colleague has done on standalone” is not something I’d recommend, SolrCloud is a different beast. Reproducing the _behavior_ is another thing, so what is the behavior you want in SolrCloud that causes you to want to customize core.properties? Best, Erick > On Sep 3, 2019, at 10:15 AM, Shawn Heisey <apa...@elyograg.org> wrote: > > On 9/3/2019 7:22 AM, Porritt, Ian wrote: >> We have a schema which I have managed to upload to Zookeeper along with the >> Solrconfig, how do I get the system to recognise both a lib/.jar extension >> and a custom core.properties file? I bypassed the issue of the >> core.properties by amending the update.autoCreateField in the Solrconfig.xml >> to false however would like to include as a colleague has done on Solr >> Standlone. > > I cannot tell what you are asking here. The core.properties file lives on > the disk, not in ZK. > > I was under the impression that .jar files could not be loaded into ZK and > used in a core config. Documentation saying otherwise was recently pointed > out to me on the list, but I remain skeptical that this actually works, and I > have not tried to implement it myself. > > The best way to handle custom jar loading is to create a "lib" directory > under the solr home, and place all jars there. Solr will automatically load > them all before any cores are started, and no config commands of any kind > will be needed to make it happen. > >> Also from a high availability aspect, if I effectivly lost 2 of the Solr >> Servers due to an outage will the system still work as expected? Would I >> expect any data loss? > > If all three Solr servers have a complete copy of all your indexes, then you > should remain fully operational if two of those Solr servers go down. > > Note that if you have three ZK servers and you lose two, that means that you > have lost zookeeper quorum, and in that situation, SolrCloud will transition > to read only -- you will not be able to change any index in the cloud. This > is how ZK is designed and it cannot be changed. If you want a ZK deployment > to survive the loss of two servers, you must have at least five total ZK > servers, so more than 50 percent of the total survives. > > Thanks, > Shawn
