Autopurge shouldn’t matter, that’s just cleaning up old snapshots. That is, it should be configured, but having it enabled or not should have no bearing on your data disappearing.
Also, are you absolutely certain that you are using your external ZK? Check the port on the admin screen. 9983 is the default for embededded ZK. All that said, nothing in Solr just deletes all this. The fact that you only saw this on reboot is highly suspicious, some external-to-Solr process, anything from a startup script to restoring a disk image to…. is removing that data I suspect. Best, Erick > On Aug 22, 2020, at 9:24 AM, yaswanth kumar <yaswanth...@gmail.com> wrote: > > Thanks Eric for looking into this.. > > But as I said before I confirmed that the paths in zookeeper were changed to > local path than the /tmp that comes default with package. Does the zoo.cfg > need to have autopurge settings ??which I don’t have in my config > > Also I did make sure that zoo.cfg inside solr and my external zoo are > pointing to the same and have same configs if it matters. > > Sent from my iPhone > >> On Aug 22, 2020, at 9:07 AM, Erick Erickson <erickerick...@gmail.com> wrote: >> >> Sounds like you didn’t change Zookeeper data dir. Zookeeper defaults to >> putting its data in /tmp/zookeeper, see the zookeeper config file. And, of >> course, when you reboot it goes away. >> >> I’ve always disliked this, but the Zookeeper folks did it that way. So if >> you just copy zoo_sample.cfg to zoo.cfg that’s what you get, not under >> Solr’s control. >> >> As for how to recover, assuming you put your configsets in some kind of >> version control as we recommend: >> >> 0> set up Zookeeper to keep it’s data somewhere permanent. You may want to >> archive snapshots upon occasion as well. >> >> 1> save away the data directory for _one_ replica from each shard of every >> collection somewhere. You should have a bunch of directories like >> SOLR_HOME/…./collection1_shard1_replica_n1/data. >> >> 2> recreate all your collections with leader-only new collections with the >> exact same number of shards, i.e. shards with only a single replica. >> >> 3> shut down all your Solr instances >> >> 4> copy the data directories you saved in <2>. You _MUST_ copy to >> corresponding shards. The important bit is that a data directory from >> collection1_shard1 goes back to collection1_shard1. If you copy it back to >> collection1_shard2 Bad Things Happen. Actually, I’d delete the target data >> directories first and then copy. >> >> 5> restart your Solr instances and verify they look OK. >> >> 6> use the collections API ADDREPLICA to build out your collections. >> >> Best, >> Erick >> >>> On Aug 22, 2020, at 12:10 AM, yaswanth kumar <yaswanth...@gmail.com> wrote: >>> >>> Can someone help me on the below issue?? >>> >>> I have configured solr 8.2 with one zookeeper 3.4 and 3 solr nodes >>> >>> All the configs were pushed initially and Also Indexed all the data into >>> multiple collections with 3 replicas on each collection >>> >>> Now part of server maintenance these solr nodes were restarted and once >>> they came back solr could became empty.. lost all the collections .. all >>> collections specific instance directories in the path /solr/server/solr >>> Were deleted ..but data folders are intact nothing lost.. not really sure >>> on how to recover from this situation. >>> >>> Did make sure that the zoo.cfg was properly configured (permanent paths for >>> zoo data and logs instead of /tmp )as I am using external zoo instead of >>> the one that comes with solr. >>> >>> Solr data path is a nas storage which is a common for all three solr nodes >>> >>> Another data point is that I enabled solr basic authentication as well if >>> that’s making any difference. Even clusterstate , schema’s, security Json >>> were all lost.. really looking for a help in understanding to prevent this >>> happening again. >>> >>> Sent from my iPhone >>
