As far as I know, the replication is supposed to delete the old directory index. However, the initial question is "why is this new index directory being created". Are you adding/updating documents in the slave? what about optimizing it? Are you rebuilding the index from scratch in the master?
Also, What OS are you on? Tomás On Wed, Jan 18, 2012 at 3:41 PM, Dyer, James <james.d...@ingrambook.com>wrote: > I've seen this happen when the configuration files change on the master > and replication deems it necessary to do a core-reload on the slave. In > this case, replication copies the entire index to the new directory then > does a core re-load to make the new config files and new index directory go > live. Because it is keeping the old searcher running while the new > searcher is being started, both index copies to exist until the swap is > complete. I remember having the same concern about re-starts, but I > believe I tested this and solr will look at the "replication.properties" > file on startup and determine the correct index dir to use from that. So > (If my memory is correct) you can safely delete "index" so long as > "replication.properties" points to the other directory. > > I wasn't familiar with SOLR-1781. Maybe replication is supposed to clean > up the extra directories and doesn't sometimes? In any case, I've found > whenever it happens its ok to go out and delete the one(s) not being used, > even if that means deleting "index". > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > -----Original Message----- > From: Artem Lokotosh [mailto:arco...@gmail.com] > Sent: Wednesday, January 18, 2012 12:24 PM > To: solr-user@lucene.apache.org > Subject: Re: replication, disk space > > Which OS do you using? > Maybe related to this Solr bug > https://issues.apache.org/jira/browse/SOLR-1781 > > On Wed, Jan 18, 2012 at 6:32 PM, Jonathan Rochkind <rochk...@jhu.edu> > wrote: > > So Solr 1.4. I have a solr master/slave, where it actually doesn't poll > for > > replication, it only replicates irregularly when I issue a replicate > command > > to it. > > > > After the last replication, the slave, in solr_home, has a data/index > > directory as well as a data/index.20120113121302 directory. > > > > The /admin/replication/index.jsp admin page reports: > > > > Local Index > > Index Version: 1326407139862, Generation: 183 > > Location: /opt/solr/solr_searcher/prod/data/index.20120113121302 > > > > > > So does this mean the index.XXXX file is actually the one currently being > > used live, not the straight 'index'? Why? > > > > I can't afford the disk space to leave both of these around indefinitely. > > After replication completes and is committed, why would two index dirs > be > > left? And how can I restore this to one index dir, without downtime? If > > it's really using the "index.XXXXX" directory, then I could just delete > the > > "index" directory, but that's a bad idea, because next time the server > > starts it's going to be looking for "index", not "index.XXXX". And if > it's > > using the timestamped index file now, I can't delete THAT one now either. > > > > If I was willing to restart the tomcat container, then I could delete > one, > > rename the other, etc. But I don't want downtime. > > > > I really don't understand what's going on or how it got in this state. > Any > > ideas? > > > > Jonathan > > > > > > -- > Best regards, > Artem Lokotosh mailto:arco...@gmail.com >
