• FEATURES
  • PRICING
  • MARKETPLACE
  • CASE STUDIES
  • BLOG
    •

    Community v6.1.RC4 error on deployment

    Technical Questions
    #1

    Hi,
    I have just compiled the 6.1RC4 community edition version. The version works on a fresh deployment, but not when upgrading a currently in use database. It errors with -

    nested exception is liquibase.exception.MigrationFailedException: Migration failed for change set db.changelog-5.2.xml

    The upgrade is from v4.3.4 to v6.1. Attached a copy of the localhost log file detailing the migration error.
    localhost.2019-07-01.log (10.7 KB)

    Any advice or fix would be greatly appreciated.
    Thanks,
    John

    #2

    Hello @John_M

    From the error message, it appears there was another OpenSpecimen process which was holding a lock on the table dyextn_audit_events for a long time because which the upgrade failed.

    To move ahead, could you please do the following?

    1. Stop all OpenSpecimen/Tomcat processes.
    2. Ensure no processes are connected to the OpenSpecimen database. This can be verified by running ‘show processlist’ command at the MySQL client prompt.
    3. Start OpenSpecimen.

    Above should fix the issue. In case the error persists, please share the following log files (in entirety, not just the snippets/excerpts).

    1. $OS_DATA_DIR/logs/os.log
    2. $TOMCAT_HOME/logs/localhost.2019-07-01/02.log
    3. $TOMCAT_HOME/logs/catalina.out

    I hope this helps.

    Thanks,
    Vinayak

    #3

    Hello @vpawar,
    Thank you for getting back to me. I tried the upgrade again and ran the ‘show processlist’ to monitor the process. I discovered the db.changelog-5.2.xml was running correctly and it took 2.5 hours to complete, I hadn’t expected it to take so long. After the changelog-5.2 was complete the rest of the upgrade completed successfully.
    Thanks,
    John

    #4

    Hi @John_M,

    That’s interesting. For a relatively small database, the upgrade should not take more than 10 minutes. Upgrades like yours take time only when you have either a large amount of data or the database is not fine-tuned.

    To know which one is the reason, may I request you to post the output of the following queries?

    select count(*) from dyextn_audit_events;
select count(*) from os_revisions;
select activity_status, count(*) from catissue_coll_prot_reg group by activity_status;
select activity_status, count(*) from catissue_specimen group by activity_status;
select activity_status, count(*) from catissue_collection_protocol group by activity_status;
select activity_status, count(*) from catissue_user group by activity_status;

    Thanks,
    Vinayak

    #5

    Hi @vpawar,

    This was on a development machine so likely to be slower than a live server.
    I can let you know how long it takes on the live server when I deploy 6.1RC4 if of interest.

    select count() from dyextn_audit_events; = 595860
    select count(    ) from os_revisions; = 4850
    select activity_status, count() from catissue_coll_prot_reg group by activity_status; = Active 10127, Disabled 1
    select activity_status, count(    ) from catissue_specimen group by activity_status; = Active 339485, Closed 65715, Disabled 276
    select activity_status, count() from catissue_collection_protocol group by activity_status; = Active 23
    select activity_status, count(    ) from catissue_user group by activity_status; = Active 38 Locked 9

    Thanks
    John