This week I upgraded to 10.2.2 from 220.127.116.11. To do this I need to run two DSS environments which requires an MLS for each environment. So I keep primary MLS (specmom) in the 18.104.22.168 environment and upgrade my secondary MLS (specmomb) in the new 10.2.2 environment. As I upgrade SS's and OC's to the new environment I remove them from the old environment. Eventually I'm left with my original primary MLS (specmom) that I upgrade and need to re-introduce to the new as the primary MLS again. Before I start the SS for the primary MLS I open SCP for each SS in my DSS and update the Host Security to add "specmom" and then I update Location Server to make "specmom" the Main MLS and "specmomb" the Backup MLS. I then start the SS on specmom and then on my OneClick servers under Administration > Spectrum Configuration I make the same updates which unfortunately requires a restart of the OneClick server. Then I sit back and hope everything properly communicates with each other after all the updates on each server. Re-introducing the primary MLS back into the environment is probably the most challenging process of the upgrade.
Which brings me to my subject title. Am I doing the best practice or is there another documented easier procedure I should reference for future upgrades?
It sound like you covered most the bases. One other thing to check is the precedence settings on both MLS servers, specmom and specmomb. The server with the lowest precedence value will take over as the active server, so you will want the primary server to have the lowest value. By default this is 10, but can be any number.
If both servers show precedence 10, then you will want to change the precedence of specmomb to a higher value, such as 20. You can do this by stopping spectrum and reloading a copy of the SSdb from specmom, via command line '../SS-Tools/SSdbload -cm -r 20 <dbsavefilename>' from the $SPECROOT/SS directory.
If specmon is running as a higher precedence than specmomb, you will need to change the precedence on specmom to a lower number than specmomb. For example, if specmomb is running precedence 10 and specmom is precedence 20, you will need to stop Spectrum and reload the SSdb database on specmom, via command line '../SS-Tools/SSdbload -cm -r 5 <dbsavefilename>' from the $SPECROOT/SS directory.
For more information regarding the SSdbload command line see https://docops.ca.com/ca-spectrum/10-2-3/en/administrating/database-management/spectroserver-database-maintenance/ca-spectrum-database-tools/ssdbload
Thanks for responding! I did have a minor gotcha because specmomb did have a precedence of 10 and interfered when I started specmom with the same precedence value. When I built specmomb in the new environment I should have set the precedence to 20. I worked it out with a few database loads and setting the proper precedence's values. Good to know I was on track with the exception of my precedence mistake.
I guess my reply really didn't answer your question regarding the best practice for upgrading a fault tolerant DSS environment. The steps can be found here: https://docops.ca.com/ca-spectrum/10-2-3/en/installing-and-upgrading/upgrading/upgrade-best-practices-fault-tolerant-deployments
From your original post, I got the impression that you don't have a permanent Fault tolerant environment - i.e. for business as usual your environment just has a single set of SSs? Whereas the best practice doc Brad mentions is about a fully redundant fault tolerant environment where every primary SS has a secondary peer SS.
So you were necessarily having to do something a bit different anyway!
It might've been possible to modify the .hostrc files on the SSs as you went along, to keep your two environments quite separate and not have to alter precedence values (perhaps).