The backup directory should just be a clone of the index files. I'm curious to know whether it is a cp -r or a cp -lr that the replication handler produces.
You would prevent commits by telling your app not to commit. That is, Solr only commits when it is *told* to. Unless you use autocommit, in which case I guess you could monitor your logs for the last commit, and do your backup a 10 seconds after that. Upayavira On Thu, Dec 20, 2012, at 12:44 PM, Andy D'Arcy Jewell wrote: > On 20/12/12 11:58, Upayavira wrote: > > I've never used it, but the replication handler has an option: > > > > http://master_host:port/solr/replication?command=backup > > > > Which will take you a backup. > I've looked at that this morning as suggested by Markus Jelsma. Looks > good, but I'll have to work out how to use the resultant backup > directory. I've been dealing with another unrelated issue in the > mean-time and I haven't had a chance to look for any docu so far. > > Also something to note, if you don't want to use the above, and you are > > running on Unix, you can create fast 'hard link' clones of lucene > > indexes. Doing: > > > > cp -lr data data.bak > > > > will copy your index instantly. If you can avoid doing this when a > > commit is happening, then you'll have a good index copy, that will take > > no space on your disk and be made instantly. This is because it just > > copies the directory structure, not the files themselves, and given > > files in a lucene index never change (they are only ever deleted or > > replaced), this works as a good copy technique for backing up. > That's the approach that Shawn Heisey proposed, and what I've been > working towards, but it still leaves open the question of how to > *pause* SolR or prevent commits during the backup (otherwise we have a > potential race condition). > > -Andy > > > -- > Andy D'Arcy Jewell > > SysMicro Limited > Linux Support > E: andy.jew...@sysmicro.co.uk > W: www.sysmicro.co.uk >
