Hi Shawn,
> There is only one thing I know of that can delete data from an index
> without an external trigger. It is the document expiration feature.
>
> https://lucidworks.com/post/document-expiration/
>
> Without some kind of action or intentional config, Solr will never
> delete anything automatically. Solr does NOT contain any kind of
> scheduling capability, and it might never get that functionality,
> because ALL modern operating systems have something built in which can
> schedule operations.
>
> What precisely do you mean by "reset" in the above? Is the collection
> still there but empty, or is the collection gone?
>
> Can you grab and share the entire solr.log shortly after this happens,
> and the previous logfile as well, which will most likely be named
> solr.log.1?
first, thanks for your response. By "reset" I mean: collection still exists
but documents have been dropped (from actually round 50k to 0). It happened
twice within the same timeframe early in the morning the last two days so I
was wondering if something within Solr like this:
".scheduled_maintenance":{
"name":".scheduled_maintenance",
"event":"scheduled",
"startTime":"NOW",
"every":"+1DAY",
"enabled":true,
"actions"
{
"name":"inactive_shard_plan",
"class":"solr.InactiveShardPlanAction"},
{
"name":"inactive_markers_plan",
"class":"solr.InactiveMarkersPlanAction"},
{
"name":"execute_plan",
"class":"solr.ExecutePlanAction"}]}},
could be the reason for the resets due to $something =) But I'm not sure about
those
Solr maintenance things, that's why I initially asked on the mailinglist here.
But
you said Solr doesn't contain any internal scheduling capability which means
this
is probably something else. There are no crons on the operating system itself
that do
any kind of solr maintenance.
Currently logging is disabled due to performance on the live setup. But
tonight, bevor
this happens, we'll enable logging an we'll hopefully see something to track
down the
source for the documents deletion in the collection.
Thanks,
Werner
