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?
Thanks,
Paul
