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
