-
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
-
-
- Gathering Interest
- is related to
-
- Closed
- relates to
-
- Closed
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page"){kind=icon}
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-13798] Prevent Confluence startup if version of home directory and database do not match (to stop inadvertent attempt to upgrade via database backup)
aragot - I've added you to the reviewer field as you did some testing while reviewing my code. I'll leave it to you to resolve the issue when you're happy with it.
Good points, all. I've updated the description and summary to match the discussion. Please add a comment if you feel I've missed something in my clarification.
JIRA works this way:
http://confluence.atlassian.com/display/JIRA/Upgrading+JIRA
Connect JIRA to a copy of your old database — take a copy of your existing JIRA database and configure the new JIRA to use the copied database. When you first start up the new JIRA it will upgrade the database to the structure needed for the new JIRA version.
I suspect this adds to Confluence administrators expecting it to work the same way.
We should also prevent old instances from being started up against a upgraded db.
Sometimes customers may start an old instance that points to an upgraded db. This should fail with a message that the database they are pointing to has been upgraded.
Jim,
The procedure is here:
http://confluence.atlassian.com/display/DOC/Migrating+Confluence+Between+Servers
Basically you use a db dump and repoint the various configuration files appropriately.
There needs to be some way to copy a production database to a test environment to test it on a new version. Past some size zip import has problems and isn't recommended. Can't the normal start up schema check and fix?
Changing the title to reflect the problem as opposed to recommending the solution.
We should also store the current build id on the database, so that we can identify the version of an sql dump.
This is NOT A SUPPORTED WAY TO UPGRADE. Customers will lose any other information we store in the home directory or might store there in the future. Even ignoring the upgrade problem, this is a recipe for hard-to-discover data loss and pain. The fact that customers might decide to upgrade by dousing their server in honey and asking a nest of ants to reorganise the magnetic patterns on the hard drive does not mean that this is something we should support. 
We already store the build number in the VersionHistory table of the database. We should check that number on startup (after the upgrade managr has finished doing its thing) and if it doesn't match the number in confluence.cfg.xml we should throw a Johnson event explaining that the installation is broken.
Ok. I just need to check with MySQL - It works well with Hsql and Postgres.