DHIS2 Upgrade: version by version vs skipping versions

Support - Assistance technique
1

Greetings,

Would it be possible to upgrade my DHIS2 version directly from 2.39 to 2.42, without upgrading step by step?

cc:
@Markus @Gassim

2

Hi @HawraaSweidan

Welcome back to the CoP! :slight_smile:

Your question has been addressed by @tkipkurgat here: Issues Upgrading From 2.38 to 2.42 - #6 by tkipkurgat

I actually think it might be a good idea to merge the topics, but please see the solution and reply here if you have further questions. Thanks!

3

We will be installing the compatible versions of Java, Postgres and Tomcat. But is it a healthy way of upgrading DIHS2? Or it would be better moving 2.40. 2.41 and then 2.42?

4

We use Windows for DHIS2 hosting and not Ubuntu.

@Gassim @Markus @Tahir_Zaman

5

Hi @HawraaSweidan

I asked @tkipkurgat this question today during the server admin meetup call and it was within the context of LXC containers and the auto-upgrade script; however, I think the answer applies even if you are on Windows.

Here are the main points that I can recall:

  1. While Flyway script is designed to manage the upgrades so that you donā€™t need to upgrade from version to version, if you decide to use the ā€œjump upgradeā€ make sure to first test in a testing environment.
  2. In the testing environment after the upgrade, please check that there was no data loss, all apps are updated and work well, and that the performance is not worsened.
  3. He would still recommend going through the upgrade version by version
  4. In all cases, the back up is a must. In the meetup, we discussed that backup of the database itself is not enough because some instances also make use of logs (such as Glowroot) and files which in the case of ā€˜containerizedā€™ setups, if the container is removed all those files and logs are lost.

When upgrading version by version, please remember to check the upgrade notes in the release to ensure that if there are any scripts that should run before upgrading or any prerequisites are met before.

I hope this helps! If there is anything thatā€™s not clear enough please share your questions. :folded_hands:

6

Thanks @Gassim

I am currently testing an upgrade of our DHIS2 instance from 2.39.2 to 2.42.6 and encountered an issue with the Capture app after reaching 2.42 and even 2.41.

Because the direct upgrade initially encountered migration issues, I performed the upgrade sequentially:

2.39.2 ā†’ 2.40.12 ā†’ 2.41.10 ā†’ 2.42.6

The database migrations completed successfully at each stage. I also compared key Tracker record counts between 2.41 and 2.42, and they remained identical:

The DHIS2 platform itself starts successfully and the database migration completes successfully. However, when opening Capture, the application fails immediately with:

The application could not be loaded.
Please see log for details.

The browser console reports:
index-hEOab-Zb.js:401

The console also shows:



GET /api/42/dataStore/capture/ruleEngine 404
Using kotlin rule engine

The DataStore request returns:
{
ā€œhttpStatusā€: ā€œNot Foundā€,
ā€œhttpStatusCodeā€: 404,
ā€œstatusā€: ā€œERRORā€,
ā€œmessageā€: ā€œNamespace not found: ā€˜captureā€™ā€,
ā€œerrorCodeā€: ā€œE1005ā€
}
From previous Community discussions, I understand that the missing capture/ruleEngine DataStore namespace may simply result in Capture using the Kotlin rule engine, so I am not sure whether this 404 is related to the actual failure.

I have already tried clearing/reloading the DHIS2 application cache and testing in a private/incognito browser session, but the same error remains.

I also performed several metadata/database checks. So far I have found:

  • No orphaned program_attributes references to tracked entity attributes.
  • No Program Rules with missing programs.
  • Program Rule Variables using TEI_ATTRIBUTE have valid trackedEntityAttributeId references.
  • Program Rule Actions targeting tracked entity attributes have valid attribute references.
  • The /api/42/programs metadata used by Capture did not contain missing trackedEntityAttribute or data element IDs in the program/program-stage structures that I checked.
  • All tracked entity attributes have non-null sharing configuration.
  • The error occurs when opening Capture itself, before I can select a program or organisation unit.

As an additional test, I rolled the staging environment back to the 2.41.10 checkpoint. DHIS2 starts successfully on 2.41.10, although we have some issues with the newer Capture app there as well; Tracker Capture remains usable on 2.41.10.

At this stage, I have therefore kept the operational staging environment on 2.41.10 while investigating the 2.42 Capture problem.

Has anyone encountered the following error after upgrading to 2.42?

7

May I ask a quick question please, after the upgrade did you ā€˜updateā€™ all the apps in the App Management app, specifically the Capture app, Maps app, Dashboard app, Data Visualizer app?

Please try to update the apps then in the Data Administrator app > Maintenance use the ā€˜clear application cache & reload appsā€™ options. After that please try to test in your browserā€™s Guest mode to ensure itā€™s not a cache issue.

If it doesnā€™t work please let me know.. :folded_hands:

-----
Hi again @HawraaSweidan
Iā€™m wondering if updating the apps helped? Thank you!

Thanks!