12.0.1 to 12.1.1 Upgrade: Error while starting Worker Process

[KesavanElangovan]

#workloadautomation #upgrade #12.1.1 #workerprocess

 

Hi, 

 

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. 

 

Thanks,

Kesavan

 

[Michael Pirson]

Hey Kesavan,

 

Did you use the Zero Downtime Upgrade? Does the wizard show that it is complete?

[KesavanElangovan]

Michael_Pirson We didn't follow the ZDU, we went through replacing the binaries(AE, Service Manager and Utilities), upgraded the database via ucybdbld. 

[Michael Pirson]

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

[Michael Pirson]

I just realized you cant log in to check that setting. I would try:

 

SELECT * FROM OVW WHERE OVW_OH_IDNR ='508';

[KesavanElangovan]

  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.1102
ATMCQA#CP002 12.0.1+hf.5.build.1102
ATMCQA#CP003 12.0.1+hf.5.build.1102
ATMCQA#CP004 12.0.1+hf.5.build.1102
ATMCQA#WP001 12.0.1+hf.5.build.17173
ATMCQA#WP002 12.0.1+hf.5.build.3009
ATMCQA#WP003 12.0.1+hf.5.build.3009
ATMCQA#WP004 12.0.1+hf.5.build.3009
ATMCQA#WP005 12.0.1+hf.5.build.3009
ATMCQA#WP006 12.0.1+hf.5.build.17173
ATMCQA#WP007 12.0.1+hf.5.build.17173
ATMCQA#WP008 12.0.1+hf.5.build.17173
ATMCQA#WP009 12.0.1+hf.5.build.17173
ATMCQA#WP010 12.0.1+hf.5.build.17173
ATMCQA#WP011 12.0.1+hf.5.build.17173
ATMCQA#WP012 12.0.1+hf.5.build.17173
ATMCQA#WP013 12.0.1+hf.5.build.17173
ATMCQA#WP014 12.0.1+hf.5.build.17173
ATMCQA#WP015 12.0.1+hf.5.build.17173
ATMCQA#WP016 12.0.1+hf.5.build.17173
ATMCQA#WP017 12.0.1+hf.5.build.17173
ATMCQA#WP018 12.0.1+hf.5.build.17173
ATMCQA#WP019 12.0.1+hf.5.build.17173
ATMCQA#WP020 12.0.1+hf.5.build.17173

[KesavanElangovan]

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

[Michael Pirson]

Hey Kesavan,

 

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.

Regards,

Michael

[KesavanElangovan]

Michael, 

 

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. 

 

Regards,

Kesavan

[KesavanElangovan]

Michael, 

 

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!

 

- Kesavan

[Michael Pirson]

Awesome, glad to hear!