Error upgrading DB server?

[spacejanitor]

Hi all, following the instructions in UPGRADE after running svn up on my DB server.

I then ran:

Code: Select all

mysql -f --database=asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.4.sql

However I got a whole list duplicate column name errors:

Code: Select all

ERROR 1060 (42S21) at line 1168: Duplicate column name 'user_group'
ERROR 1060 (42S21) at line 1169: Duplicate column name 'user_group'
ERROR 1060 (42S21) at line 1170: Duplicate column name 'user_group'
ERROR 1060 (42S21) at line 1171: Duplicate column name 'user_group'
ERROR 1060 (42S21) at line 1173: Duplicate column name 'max_calls_method'
ERROR 1060 (42S21) at line 1174: Duplicate column name 'max_calls_count'
ERROR 1060 (42S21) at line 1175: Duplicate column name 'max_calls_action'
ERROR 1050 (42S01) at line 1182: Table 'dialable_inventory_snapshots' already exists
ERROR 1060 (42S21) at line 1205: Duplicate column name 'svn_version'
ERROR 1060 (42S21) at line 1209: Duplicate column name 'campaign_grade'
ERROR 1060 (42S21) at line 1211: Duplicate column name 'group_grade'
ERROR 1060 (42S21) at line 1213: Duplicate column name 'group_grade'
ERROR 1060 (42S21) at line 1215: Duplicate column name 'campaign_grade'
ERROR 1050 (42S01) at line 1221: Table 'vicidial_daily_max_stats' already exists

Can anybody advise what to do about this?

[spacejanitor]

I'm assuming that is normal, so I went ahead with the other steps.

However, my version and build numbers in the admin GUI are still what they were before the upgrade. Any idea why that might be?

[williamconley]

What version are you trying to upgrade ... to? 2.4 or 2.6?

When we upgrade, we ordinarily edit the upgrade sql file and delete all commands preceding our present version to avoid collisions. Doesn't happen very often ... but if you delete all the commands that have already run, it NEVER happens. LOL

Also, I note you have posted here quite a bit and you did not post your vicibox VERSION or your asterisk version or the rest ... tsk.

[spacejanitor]

Its in my signature!

I am upgrading from a 2.4 to the newest 2.4 revision. I used the 3.1.15 vicibox iso initially. All servers in the cluster are using Asterisk 1.4

Is the 2.6 release completely stable, and recommended for upgrade?

[spacejanitor]

Ok, so I deleted everything in the UPGRADE_2.4.sql that preceded my db schema version (1312) and ran it... now it executed without any problems.

I did SVN up on all machines and ran the install as well... rebuilt the conf files... rebooted.

Now, strangely enough, the db schema field under Admin -> System Settings is empty. Same with the "Version", "DB Schema Update Date", "Auto User-add Value", "Install Date"...

HOWEVER the build number in the lower left corner has been updated:
VERSION: 2.6-372a
BUILD: 120713-2123

This doesn't look right... I ran the UPGRADE_2.4.sql command not the 2.6!

[spacejanitor]

Also what is a little bit concerning is that I no longer have a "LISTS" link in the admin gui!

Yes... everything looks a little "off" here. I don't think the DB sql upgrade went as planned.

[williamconley]

did you reboot?

Honestly, I've never had a problem with an "upgrade" unless I did not delete those previous entries.

I will, however, state that if you were working from the previously "failed" DB after that prior upgrade attempt failed, instead of restoring and trying again, there could have been some residual effect (ie: damage already done). That shouldn't be possible, but it could be. LOL

Also: Have you modified your Asterisk DB (customized) at all before this upgrade? (Modifications will generally have a collision with an upgrade, as Vicidial accesses fields NOT by name but by "order")

[spacejanitor]

Yes - rebooted.

Would these issues be consistent with a failed DB upgrade? The admin interface is messed up now - missing links to LISTS, campaign details missing, etc.

Or could that have occurred because from upgrading the apache/telephony servers too? The strangest thing is that it's showing it's on version 2.6 now even though I didn't touch that upgrade script.

This might be a problem with the code on the apache or telephony servers. It may be requesting fields that were never put in in that SQL update.

[williamconley]

Yes. Missing items from GUI pages is consistent with a failed DB upgrade.

If you upgraded to 2.6 by accident (which is trunk at present) that would definitely explain it. Your WEB is 2.6 but your DB is 2.4 ... so upgrade your DB to 2.6! LOL

[spacejanitor]

I shall try! I thought updating from SVN would stay with the 2.4 release.

[spacejanitor]

Good call - that appears to have fixed it. Thanks Bill!

I thought the 2.4 trunk was a completely separate trunk from 2.6 and so doing svn up wouldn't go to 2.6. Now I know better!

[williamconley]

the definition of trunk = "latest in development". at one point trunk has been every version during development.

when a new "branch" develops because of a release (or release candidate), "trunk" moves to the next version.

note to consider: "trunk" is NOT "latest stable release", it is "developer trunk" (which CAN be unstable!).

Just a thought.

To remain at 2.4 (latest stable!):

Code: Select all

svn co svn://svn.eflo.net:43690/agc_2-X/branches/agc_2.4

this will result in an "agc_2.4" folder. Then you'll install from that instead of the old "trunk" folder. And as "bug fixes" are committed to that 2.4 branch, updating that branch will include them without moving to 2.6.

[spacejanitor]

Oh boy. What's the easiest way to go back to the 2.4? Restore the backups on the cluster?

After calling that svn command for the 2.4 release which you wrote above, all of the rest of the instructions will be the same? I mean, running "svn up" will just update to the latest 2.4?

[williamconley]

Yes.

Yes. (but do be careful to "install.pl" from the 2.4 folder and not the trunk folder ... and svn up in the 2.4 folder ...).

It should become clear after you see that there are two folders after the svn command (which you will run in /usr/src/astguiclient ...)

[spacejanitor]

Thanks. Will try this shortly.