#workloadautomation #upgrade #12.1.1 #workerprocess
I followed the documentation to upgrade our 12.0.1 to 12.1.1.
Stopped all the clients
Stopped all the agents(wasn't mentioned in the document)
Backed up AutomationEngine, ServiceManager, Utilities of 12.0.1
Configured the 12.1.1 binaries of AutomationEngine, ServiceManager and Utilities
Upgraded the database.
Started the Service Manager and when trying to start the 1st WP to be the PWP, it goes down with the below error:
U00015000 WP 'ATMCQA#WP001' cannot be primary, because it is using another MQSet than the old primary WP ('2' instead of '1'). Please start a WP with an older version.
I tried ColdStart, but same result.
Any ideas of what might be the fix/solution.
Did you use the Zero Downtime Upgrade? Does the wizard show that it is complete?
Michael_Pirson We didn't follow the ZDU, we went through replacing the binaries(AE, Service Manager and Utilities), upgraded the database via ucybdbld.
That is what I figured from your upgrade steps. What do you have for ZDU in the UC_SYSTEM_SETTINGS in client 0. I dont see why it would be using the other MQset
I just realized you cant log in to check that setting. I would try:
SELECT * FROM OVW WHERE OVW_OH_IDNR ='508';
ZERO_DOWNTIME_UPGRADE set to Y
Also, in the OH/HOST table I see the below entry.
ATMCQA#CP001 12.0.1+hf.5.build.1102ATMCQA#CP002 12.0.1+hf.5.build.1102ATMCQA#CP003 12.0.1+hf.5.build.1102ATMCQA#CP004 12.0.1+hf.5.build.1102ATMCQA#WP001 12.0.1+hf.5.build.17173ATMCQA#WP002 12.0.1+hf.5.build.3009ATMCQA#WP003 12.0.1+hf.5.build.3009ATMCQA#WP004 12.0.1+hf.5.build.3009ATMCQA#WP005 12.0.1+hf.5.build.3009ATMCQA#WP006 12.0.1+hf.5.build.17173ATMCQA#WP007 12.0.1+hf.5.build.17173ATMCQA#WP008 12.0.1+hf.5.build.17173ATMCQA#WP009 12.0.1+hf.5.build.17173ATMCQA#WP010 12.0.1+hf.5.build.17173ATMCQA#WP011 12.0.1+hf.5.build.17173ATMCQA#WP012 12.0.1+hf.5.build.17173ATMCQA#WP013 12.0.1+hf.5.build.17173ATMCQA#WP014 12.0.1+hf.5.build.17173ATMCQA#WP015 12.0.1+hf.5.build.17173ATMCQA#WP016 12.0.1+hf.5.build.17173ATMCQA#WP017 12.0.1+hf.5.build.17173ATMCQA#WP018 12.0.1+hf.5.build.17173ATMCQA#WP019 12.0.1+hf.5.build.17173ATMCQA#WP020 12.0.1+hf.5.build.17173
ZERO_DOWNTIME_UPGRADE set to Y
Also, in the OH/HOST table I see entries for previous version of the AE for all the CPs, WPs
Ah, yeh that is what got you. I bet the DBload log shows it changing the MQSET because it saw Y in that variable position. I'd update that to N and rerun the load, however that is totally not supported.
If I were you:
1. Try to start a WP/CP with the old binary version, change that to N in client 0 and rerun the DBload.
2. Ask CA support what the supported method is to correct this.
That totally makes sense. I had upgraded another environment without any issues. I just checked ran the query against that database and ZERO_DOWNTIME_UPGRADE set to N.
However, when I compared the DBLoad log, there wasn't any difference. In particular I didn't locate the work 'MQSET' in it.
But, thanks for the direction. Much appreciated. Will keep posted on how it works out.
I restored the database back to 12.0.1, with Automic support's recommendation updated the OVW_Value1 in the table OVW to N. Re-ran the upgrade DBLoad script and was able to get the AE up and running. Thanks again!
Awesome, glad to hear!