FN19497

From TBwiki
(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
{{DISPLAYTITLE:FN19497 - Procedure to Recover a Major Upgrade after Recovering Database from Newer Version to Older Version }}
+
{{DISPLAYTITLE:FN19497 - Major Upgrade failure on system running with a database from newer Version}}
  
 
= Affected Products =
 
= Affected Products =
Line 5: Line 5:
  
 
= Problem Description =
 
= Problem Description =
* Import a database backup from a newer version to an older version. e.g. Imported a database backup from rel2.9 to a TMG which is running rel2.7.175 (or older)
+
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.
* Validate/Recover the database
+
* Do a major upgrade on the TMG
+
  
= Problem Symptoms =
+
== 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
 +
 
 +
{| class="wikitable"
 +
|-
 +
! 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
 
* Upgrade fails, always switch back to the old version
 
* tboamapp logs shows: database_upgrade: [FAIL]    ERROR: data upgrade 26 failed: ERROR: data upgrade 26
 
* tboamapp logs shows: database_upgrade: [FAIL]    ERROR: data upgrade 26 failed: ERROR: data upgrade 26
 +
  
 
= Solution =
 
= 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.
  
1- ssh to the TMG host
 
2- stop toolpack by shell command: tbtoolpack stop
 
  [root@TB007036 ~]# tbtoolpack stop
 
  0:tbtoolpack_12358
 
  Stopping tbtoolpack_12358:                                [  OK  ]
 
  Toolpack current state: Disconnected
 
  Ok
 
  
2- Drop both databases: toolpack_0 and toolpack_2_x
+
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
  [root@TB007036 ~]# mysql -u tbdb -ptbdbpw
+
  Welcome to the MySQL monitor. Commands end with ; or \g.
+
  Your MySQL connection id is 116
+
  Server version: 5.1.47-log Source distribution
+
  Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
+
  This software comes with ABSOLUTELY NO WARRANTY. This is free software,
+
  and you are welcome to modify and redistribute it under the GPL v2 license
+
  Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
+
  
   mysql> drop database toolpack_0;
+
1. Recover from a valid 2.7 database backup or a previous release backup. Skip to steps 4a or 4b.
   mysql> drop database toolpack_2_x;
+
 
 +
 
 +
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":
  
3- Check the config files to make sure it is pointing to the new release.
 
  Below is an exmaple to start toolpack in rel2.9.41:
 
 
   vi /lib/tb/toolpack/setup/12358/service/config.txt
 
   vi /lib/tb/toolpack/setup/12358/service/config.txt
  Make sure it the applicaiton path is:
 
  application= /mnt/.0/tb/toolpack/setup/12358/2.9/apps/tboamapp/tboamapp_wd_cfg.ini
 
  vi /mnt/.0/tb/toolpack/setup/12358/2.9/apps/tboamapp/tboamapp_wd_cfg.ini
 
  Make sure package path is 2.9.41
 
  TB_PKG_PATH                    = /lib/tb/toolpack/pkg/2.9.41
 
  
4- Manually start toolpack on the newer release
+
Make sure that the 'application=' line contain '2.8'.
   [root@TB007036 ~]# tbtoolpack start
+
 
  0:tbtoolpack_12358
+
  application= /lib/tb/toolpack/setup/12358/2.8/apps/tboamapp/tboamapp_wd_cfg.ini
  Starting tbtoolpack_12358:                                 [  OK  ]
+
 
  Toolpack current state: Ready
+
Restart toolpack
   Ok
+
   # 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.'''

Revision as of 17:07, 5 July 2016


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:

  1. Recover from a valid database backup (from a previous or actual release). The backup could also be imported from another system.
  2. 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.

Personal tools