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.
