lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Rosen <>
Subject Need deployment strategy
Date Wed, 13 Jan 2010 22:38:33 GMT
Hi all,

The way the indexing works on our system is as follows:

We have a separate "staging" server with a copy of our web app. The 
clients will index a number of documents in a batch on the staging 
server (this happens about once a week), then they play with the results 
on the staging server for a day until satisfied. Only then do they give 
the ok to deploy.

What I've been doing is, when they want to deploy, I do the following:

1) merge and optimize the index on the staging server,

2) copy it to the production server,

3) stop solr on production,

4) copy the new index on top of the old one,

5) start solr on production.

This works, but has the following disadvantages:

1) The index is getting bigger, so it takes longer to zip it and 
transfer it.

2) The user is only added a few records, yet we copy over all of them. 
If a bug happens that causes an unrelated document to get deleted or 
replaced on staging, we wouldn't notice, and we'd propagate the problem 
to the server. I'd sleep better if I were only moving the records that 
were new or changed and leaving the records that already work in place.

3) solr is down on production for about 5 minutes, so users during that 
time are getting errors.

I was looking for some kind of replication strategy where I can run a 
task on the production server to tell it to merge a core from the 
staging server. Is that possible?

I can open up port 8983 on the staging server only to the production 
server, but then what do I do on production to get the core?


View raw message