Our main issue is for new index we need to update DB first as data needs to
be pulled from DB as per new schema and publish to Solr.
So DB update has to be first step.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Production-Release-process-with-Solr-3-5-implementation-t
Why not to change the order to this:
3. Upgrade Solr Schema (Master) Replication is disabled.
4. Start Index Rebuild. (if step 3)
1. Pull up Maintenance Pages
2. Upgrade DB
5. Upgrade UI code
6. Index build complete ? Start Replication
7. Verify UI and Drop Maintenance Pages.
So your slaves will
On 11/1/2012 2:46 PM, adityab wrote:
1. Pull up Maintenance Pages
2. Upgrade DB
3. Upgrade Solr Schema (Master) Replication is disabled.
4. Start Index Rebuild. (if step 3)
5. Upgrade UI code
6. Index build complete ? Start Replication
7. Verify UI and Drop Maintenance Pages.
As # 4 takes couple
Thanks Paul,
In our case we need to upgrade DB with new version before re-building the
index as we pull data from DB.
Once DB is upgraded, UI needs to be upgraded too.
We do the same in case when there is no DB schema changes. We disable the
replication and build index on Master. Once index is
Here is what we do for Curriki.org:
We run a background indexing by setting up another solr that performs all the
indexing.
Then we can start the install process.
Then we can update the index with the things changed since the background
indexing.
paul
Le 1 nov. 2012 à 21:46, adityab a écrit :
Hi,
My question is generally to understand how people are dealing with such
situation to minimize production downtime. Any suggestion/advice are
welcomed.
We have Solr 3.5 setup as master Slave. Our UI almost has 70% data fetched
from Solr Slaves where as other 30% are for authentication and oth
