FN19497 - Major Upgrade failure on system running with a database from newer Version
Contents |
Affected Products
- TMG800, TMG3200, TMG7800-CTRL running Toolpack software older than rel2.7.176
Problem Description
Importing a database from a newer major release to a older major release is not supported (e.g. import a database from a system running 2.9 to a 2.7 system). Previous to release 2.7.176, there was no mechanism in the web portal to prevent doing such action. From 2.7.176 onward, the validation and recover would fail to prevent such action. The upgrade of a system in such state would result in a failure of the upgrade.
How to get into the issue
- Import a database backup from a newer major release to an older release previous to 2.7.176. e.g. Import a database backup from rel2.9 to a TMG which is running rel2.7.175 (or older)
- Validate/Recover the database backup (validation and recover would be performed)
How to validate your system database
Each time a database backup is recovered, the system proceed to the following actions:
- perform an automatic backup of the actual database (under Backups->Automatic database backups)
- erase the actual database and replace it by the new database (recovered)
- proceed to the database data upgrade to match the actual system's version
| Release | Database Name | Unique data upgrade number |
|---|---|---|
| Release 2.6 | toolpack_0 | 3 |
| Release 2.7 | toolpack_0 | 15 |
| Release 2.8 | toolpack_2_8 | 44 |
| Release 2.9 | toolpack_2_9 | 57 |
# mysql -u tbdb -ptbdbpw -e "select * from database_name.current_data_upgrades order by CAST(id as SIGNED INTEGER) asc;"
To make sure your system does not run with an newer version database, you can look at the database data upgrades table and make sure that is does not include upgrades from newer releases. Note that some upgrade number are common to more than one release, for example the upgrade number '61', '63', '73', etc.. are common to both 2.8 and 2.9 releases. The table above provides unique data upgrade for a particular major release. For example, the data upgrade '57' can only be found if the database data have been updated from a 2.9 release.
For, example, if your system runs Release 2.7, in the command above replace database_name by "toolpack_0" to get the list of upgrades performed on your database:
# mysql -u tbdb -ptbdbpw -e "select * from toolpack_0.current_data_upgrades order by CAST(id as SIGNED INTEGER) asc;" +-----+---------------------------------------------------------------------------------------------------------------------+ | id | description | +-----+---------------------------------------------------------------------------------------------------------------------+ | 0 | Move fax behavior enable to profiles and fix default passthrough detection type. | | 1 | Remove unique constraint on gateway configurations for RADIUS server configurations. | | 2 | Remove the USING BTREE attribute from the RADIUS server configurations table. | | 3 | Change the RADIUS dictionary for attributes 1-29. | | 4 | Re-use the value from field nat_traversal as the new remote_nat_traversal_method_id on table nap_sip_cfgs | ... | 44 | Create the default tone definition profiles. | | 45 | Create custom tone definition profiles with current data. | | 46 | Update the RADIUS dictionary to modify attributes (changed RemoteIp/RemotePort). | | 48 | Re-generate some unique ids that were previously improperly generated. |
For example, if you find the data upgrade number '44' in the list, it would indicate that the data of this database have been updated by a 2.8 system. If you find the upgrade number '57', the database come from a 2.9 system, and so on.
If you find out that your database data comes from a newer release, you must:
- Recover from a valid database backup (from a previous or actual release). The backup could also be imported from another system.
- There is no conversion tools to take the data of a newer release and transform it to an older release. Therefore, you might have manually reconfigure your system from the latest valid backup found.
Problem Symptoms
If your database data have been previously updated by a new release, performing a major upgrade would lead to a failure of the data upgrade:
- Upgrade fails, always switch back to the old version
- tboamapp logs shows: database_upgrade: [FAIL] ERROR: data upgrade 26 failed: ERROR: data upgrade 26
Solution
If your database was previously updated from a newer release (as described above), and you inadvertently upgraded your system to a newer release and failed. You must recover your database with one from the release your were running previous to the upgrade.
For example, lets say your database was recovered from a 2.9 system on a 2.7 system and the activate package to 2.8 have failed; system fall back on 2.7
1. Recover from a valid 2.7 database backup or a previous release backup. Skip to steps 4a or 4b.
If for some reason you can't recover a valid database, erase the databases to force the system to create new ones:
2. ssh to your TMG host
3. Drop the 2.7 database (toolpack_0) and the 2.8 database (toolpack_2_8):
# tbtoolpack stop # mysql -u tbdb -ptbdbpw -e "drop database toolpack_0;" # mysql -u tbdb -ptbdbpw -e "drop database toolpack_2_8;"
4a. If you upgrade from a release previous to 2.7.148, you must follow the instruction below:
# tbtoolpack stop
Edit the following file with "vi":
vi /lib/tb/toolpack/setup/12358/service/config.txt
Make sure that the 'application=' line contain '2.8'.
application= /lib/tb/toolpack/setup/12358/2.8/apps/tboamapp/tboamapp_wd_cfg.ini
Restart toolpack
# tbtoolpack start
4b. If you upgrade from a release supporting major release upgrade from the web (2.7.148 and above), you must follow the instruction below:
Restart toolpack
# tbtoolpack start
From the Web portal, activate package 2.8.
