As part of our Change Management process we need to include rollback plans. We normally upgrade the server, which then automatically upgrades the collectors, which then automatically update the agents. Rolling all that back could be "interesting". Any hints on keeping the corporate types off our backs by sharing instructions about how to roll all three back after an errant upgrade? Not that anything ever could go wrong, of course!
Answer by Srikar M. ·
Adding to the great details provided by James...
With regards to upgrade, from a high level, here are the implementation steps...(back up db, session store and config files; acquire the new license and uem before hand); disconnect the performance warehouse; deactivate the license and uem volume; stop the collector service, stop the server service; Install the new version for server and collector (as you can see the old version still exists); run the migration commands to port configurations from old version to new; bring up the new server service then the collector service; import the new license; connect to performance warehouse. If an application is restarted at this time the bootstrapped agents will be updated;
From a roll back strategy consider these points...once the new server service connects to the performance warehouse it will update the schema (if any) - so from a roll back point of view have a db backup that can be restored, you also want to back up the session store for restoring it. For server and collector service you can stop the current (new) service and start the old one (at this point you will have to restore the db and session store)...for the agent you can re-install the older version.
Hope this helps.
Srikar
Answer by David W. ·
Great feedback!
We do a variation of James' B - we do a side-by-side with the server and collectors. So, rollback for those is straightforward by going back to the earlier versions it appears.
That leaves the question of the agents. Are you saying that when they "phone home" they will automatically go back to the previous version? Otherwise, we have hundreds of agents (potentially) that would have to be manually rolled back. Major ugh!
Answer by James D. ·
Hey David, we also have a strict change process that requires a back-out plan. We looked at a few options for ours since older versions of dynaTrace are less than friendly for these types of scenarios. We actually DON'T auto-update our agents. A long time ago in v4 we had an agent cause a performance problem with one system. Since then we were gun shy of course. So, we now roll out agents per machine/application.
In both instances you can lose session data if your transaction storage is on the same drives, or is backed up.
Scenario A - Install/Back-out using backup using bootstrap agents
Scenario B - Install/Back-out side by side using bootstrap agents
Scenario C - Install/Back-out side by side using non-bootstrap agents
JANUARY 15, 3:00 PM GMT / 10:00 AM ET