com.atlassian.confluence.upgrade.UpgradeException: Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com.

Atlassian JIRA | Paul Curren | 8 years ago
tip
Click on the to mark the solution that helps you, Samebug will learn from it.
As a community member, you’ll be rewarded for you help.
  1. 0

    When trying to upgrade QA-EAC recently, the upgrade failed with the message - {noformat} 2009-06-02 00:23:01,940 FATAL [main] [atlassian.confluence.upgrade.UpgradeLauncherServletContextListener] contextInitialized Upgrade failed, application will not start: Cannot proceed with upgrade. Cluster upgrade lock ac quired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluste r. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com. com.atlassian.confluence.upgrade.UpgradeException: Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com. at com.atlassian.confluence.upgrade.impl.DefaultUpgradeManager.permitDatabaseUpgrades(DefaultUpgradeManager.java:134) {noformat} The problem is that the CONFVERSION entry for the current build (1624 in this case) already has the pre_upgrade_version entry indicating it has been upgraded. This will probably happen if the server is stopped or throws an exception during the upgrade. The individual upgrade tasks are wrapped in a transaction and the VersionHistoryDao is also wrapped (responsible for adding the tag). However, the DefaultUpgradeManager is not wrapped in a transaction so when it catches any exceptions during upgrade the changes it has made (using the VersionDataDao) will not be rolledback. That's my theory anyway.

    Atlassian JIRA | 8 years ago | Paul Curren
    com.atlassian.confluence.upgrade.UpgradeException: Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com.
  2. 0

    When trying to upgrade QA-EAC recently, the upgrade failed with the message - {noformat} 2009-06-02 00:23:01,940 FATAL [main] [atlassian.confluence.upgrade.UpgradeLauncherServletContextListener] contextInitialized Upgrade failed, application will not start: Cannot proceed with upgrade. Cluster upgrade lock ac quired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluste r. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com. com.atlassian.confluence.upgrade.UpgradeException: Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com. at com.atlassian.confluence.upgrade.impl.DefaultUpgradeManager.permitDatabaseUpgrades(DefaultUpgradeManager.java:134) {noformat} The problem is that the CONFVERSION entry for the current build (1624 in this case) already has the pre_upgrade_version entry indicating it has been upgraded. This will probably happen if the server is stopped or throws an exception during the upgrade. The individual upgrade tasks are wrapped in a transaction and the VersionHistoryDao is also wrapped (responsible for adding the tag). However, the DefaultUpgradeManager is not wrapped in a transaction so when it catches any exceptions during upgrade the changes it has made (using the VersionDataDao) will not be rolledback. That's my theory anyway.

    Atlassian JIRA | 8 years ago | Paul Curren
    com.atlassian.confluence.upgrade.UpgradeException: Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com.

    Root Cause Analysis

    1. com.atlassian.confluence.upgrade.UpgradeException

      Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com.

      at com.atlassian.confluence.upgrade.impl.DefaultUpgradeManager.permitDatabaseUpgrades()
    2. com.atlassian.confluence
      DefaultUpgradeManager.permitDatabaseUpgrades
      1. com.atlassian.confluence.upgrade.impl.DefaultUpgradeManager.permitDatabaseUpgrades(DefaultUpgradeManager.java:134)
      1 frame