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 continue to serve traffic until you're done with the master index. Or the master index also imports from the same database? On Thu, Nov 1, 2012 at 4:08 PM, Shawn Heisey <s...@elyograg.org> wrote: > 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 of hours compared to all other steps which run within >> few minutes, we need to have down time for the duration of that. >> > > What I do is a little bit different. I have two completely independent > copies of my index, no replication. The build system maintains each copy > simultaneously, including managing independent rebuilds. I used to run two > copies of my build system, but I recently made it so that one copy manages > multiple indexes. > > If I need to do an upgrade, I will first test everything out as much as > possible on my test environment. Then I will take one copy of my index > offline, perform the required changes, and reindex. The UI continues to > send queries to the online index that hasn't been changed. At that point, > we initiate the upgrade sequence you've described, except that instead of > step 4 taking a few hours, we just have to redirect traffic to the brand > new index copy. If everything works out, we then repeat with the other > index copy. If it doesn't work out, we revert everything and go back to > the original index. > > Also, every index has a build core and a live core. I currently maintain > the same config in both cores, but it would be possible to change the > config in the build core, reload or restart Solr, do your reindex, and > simply do a core swap, which is almost instantaneous. If you are doing > replication, swapping cores on the master initiates full replication to the > slave. Excerpt from my solr.xml: > > <core instanceDir="cores/s0_1/" name="s0live" > dataDir="../../data/s0_1"/> > <core instanceDir="cores/s0_0/" name="s0build" > dataDir="../../data/s0_0"/> > > Thanks, > Shawn > > P.S. Actually, I have three full copies of my index now -- I recently > upgraded my test server so it has enough disk capacity to hold my entire > index. The test server runs a local copy of the build system which keeps > it up to date with the two production copies. > >
