Hi Otis, Thank you for your reply. I'm in the middle of that upgrade and will report back when testing is complete. I'd like to get some nice set of reproducible steps so I'm not just ranting on. :)
Regards, Gilles -----Original Message----- From: Otis Gospodnetic [mailto:otis.gospodne...@gmail.com] Sent: 20 May 2013 04:29 To: solr-user@lucene.apache.org Subject: Re: .skip.autorecovery=Y + restart solr after crash + losing many documents Hi Gilles, Could you upgrade to 4.3.0 and see if you can reproduce? Otis -- Solr & ElasticSearch Support http://sematext.com/ On Mon, May 13, 2013 at 5:26 PM, Gilles Comeau <gilles.com...@polecat.co> wrote: > Hi all, > > We write to two same-named cores in the same collection for redundancy, and > are not taking advantage of the full benefits of solr cloud replication. > > We use solrcloud.skip.autorecovery=true so that Solr doesn't try to sync the > indexes when it starts up. > > However, we find that if the core is not optimized prior to shutting it down > (in a crash situation), we can lose all of the data after starting up. The > files are written to disk, but we can lose a full 24 hours worth of data as > they are all removed when we start SOLR. (I don't think it is a commit issue) > > If we optimize before shutting down, we never lose any data. Sadly, > sometimes SOLR is in a state where optimizing is not an option. > > Can anyone think of why that might be? Is there any special configuration > you need if you want to write directly to two cores rather than use > replication? Version 4.0, this used to work in our 4.0 nightly build, but > broke when we migrated to 4.0 production. (until we test and migrate to > the replication setup - it won't be too long and I'm a bit embarrassed to be > asking this question!) > > Regards, > > Gilles >
