Upgrade pains with Confluence

Question

confluence upgrade:
- Prepped yesterday to go from current 6.13.0 to newest I find on internal repo: 7.0.1 (tar.gz file)
- Backed up linux files for 6.13.0 (59G) this morning at 7:30am CT
- Placed new 7.0.1 files... Startup attempt 1... (missing confl home dir config)...ERROR. Fixed. Startup attempt 2... 8:06:00 am CT... waited forever... seemingly doing nothing. Gave up at 8:50:05 am CT.
- Tried tinkering ... no luck
- Decided to go to our repo's highest 6.x version with an executable script to do the upgrade (6.15.9) atlassian-confluence-6.15.9-x64.bin
- Answered upgrade questions on command line... didn't let it start itself. (I have to modify 6 or so configs first)... so I did that and tried starting at 9:35:51am CT... still waiting with no sign its getting anywhere.   Gave up after 30 mins.

Since I didn't let the first attempt start itself... tried a different approach...
When it asks me that question... this time... quickly place all the files I want to modify... then answer Yes. Last attempt around 10:25am CT.... waiting...

It reports:
Confluence 6.15.9 may take several minutes to load on first start up.
Finishing installation ...

Keep getting emails from our user base about:  "Did you know confluence is down?"

It feels like some DB update scripts are not firing maybe... highest DB version using:

select * from CONFVERSION;

... matches the old  version build number used when it was 6.13.0

The CPU use is small.  The logs have been silent since a few seconds after startup.  If it's doing something useful it doesn't indicate this.

Upgrading build numbers in confluence.cfg.xml doesn't help and isn't recommended anyway since it errors out in that case saying the DB and the config file do not match.

Shouldn't the executable upgrade script take care of those updates to the DB and the confluence.cfg.xml configuration file both... getting it upgraded and getting us back on our feet so we can use the software?

What else can be done?

Jeff Kell · Answer

Thanks for your ideas. I may try them on the next attempts next week. Oracle is on an external machine. The connection is fine prior to upgrade and after rollback. In previous attempts in past months for other installs/upgrades, I've noticed the top tag here for setupStep seems change to different values until finally landing on complete. complete custom 7901 I know it is not conventional, but maybe knowing a different value instead of "Complete" would cause some background DB update scripting to happen. I suppose the Confluence developers know of such shortcuts but they're probably not advertised for the public.

Andrew Laden · Answer

Nope, its confluence itself that does the upgrade, not the upgrade binary file. thats why you can just drop the new tar.gz file in place. All the upgrade binary really does is check for changed files, then basically remove the home directory and drop in the new version. and tweak a few files.

You can get rid of the cfg.xml (save a copy first) file and see if confluence prompts you to create a new one, just to see if the binary itself all is working. That would be a way to get it to prompt you about what database to connect to.

Does your oracle server show any connections? (is it on the same machine or a different one?)

Jeff Kell · Answer

Using Oracle. The tomcat logs stop cold a few seconds after startup. The "top" command shows CPU at or below 1% ...waited over 1 hour on last attempt. Finally rolled back by removing "/confluence/" which was the only directory updated ... and put back old 6.13.0 version to "/confluence/" ... startup... This time took about 5-6 mintues to get login screen and succesfully login. So at least the rollback method I'm using is working. One thought is to... maybe avoid placing the odjbc*.jar into .. confluence/WEB-INF/lib... and see if I get some modified startup screen asking me which DB to connect to... but I'm concerned with this approach because I don't want it to clobber existing DB content. And I don't even know if this would work anyway. The DB config things exist under application-data/confluence/confluence.cfg.xml which is all in a separate directory from the "/confluence/" directory containing version specific installed files and configurations. My hope was that the executable binary itself, when selecting upgrade, would do what it must regarding the DB changes (if any exist) and the buildNumber tag in confluence.cfg.xml itself. Maybe the upgrade doesn't see those files under the very large application-data directory? It gives no indication of this on the tomcat logs. Will probably attempt this again next week if I can find any useful information regarding what I might be missing.