Only an optimize or a large fragment merge would cause a large file deposits there. That’s why “slaves” should always have double the index size available as solr will decide on its own when to merge or optimize on the master so the slaves need to be ready for double the size, and the master needs to be ready for triple the size. If you don’t have the disk space ready to handle this you’re going to eventually run into some serious issues, or just not be able to replicate
-dave > On Oct 10, 2022, at 2:56 PM, mtn search <search...@gmail.com> wrote: > > As I go back through > https://solr.apache.org/guide/6_6/index-replication.html, the picture is > filling in a little more. My guess the tmp dir referenced, is the > index.<timestamp> dir. > > Very interested in cases that might generate a full replication. To my > knowledge no optimize commands has been issued against the core in question. > >> On Mon, Oct 10, 2022 at 12:38 PM mtn search <search...@gmail.com> wrote: >> >> Hello, I am learning more about replication as I maintain a large Solr 6 >> set of Solr servers configured for Master/Slave. >> >> I noticed during some replication activities in addition to the original >> index dir under the core name on the file system is a dir named "index" >> with a timestamp. index.<timestamp>. Files are written to this dir with >> the timestamp during replication. I am interested in how this works: >> >> For every core replicating to it's master is this timestamped dir >> created? >> >> Or is this timestamped dir created/used for only special circumstances? >> If so, what? >> >> - Are there cases that cause a full replication within Solr 6? >> >> Is the original index dir removed and the time stamped dir renamed to >> "index" after replication? >> >> I initially figured all replication activities happened within the index >> dir, but that does not appear to be the case. >> >> Any tips, or documentation references would be appreciated. >> >> Thanks, >> Matt >>
