-
Suggestion
-
Resolution: Fixed
-
3
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
Currently the upgrade process checks the build ID against confluence.cfg.xml to see whether the user is trying to upgrade. In addition, the build number stored in the database should be checked to prevent problematic upgrades.
Customers might inadvertently do the following while trying to upgrade Confluence:
- Install latest version distribution
- Create new database
- Run through setup wizard
- Restore sql dump from old version
The procedure is completely broken because it loses all information stored in the home directory (such as attachments), but Confluence doesn't currently do anything to prevent it.
At the moment, the upgrade process does not start because the home directory version number (in confluence.cfg.xml) matches the build number stored in the application itself. The application starts up with the old data, and with a reindex it can look as if Confluence is mostly working. Only much later can the failure of some operation with the home directory data expose the upgrade as a complete disaster.
If the upgrade process also checked the version number stored in the database and stopped Confluence starting if the home directory and database didn't match, it would make this situation easier to diagnose and prevent customers using Confluence after such a failed upgrade.
- causes
-
CONFSERVER-31675 BootstrapManager blocks in-place upgrades for cluster installations
- Closed
-
CONFSERVER-18085 Need an integrity checker to check all required database tables exist after an upgrade
- Gathering Interest
- is related to
-
CONFSERVER-12947 Do not allow older versions of Confluence to run against newer Confluence homes
- Closed
- relates to
-
CONFCLOUD-13798 Prevent Confluence startup if version of home directory and database do not match (to stop inadvertent attempt to upgrade via database backup)
- Closed