community.aegirproject.org

2:46pm Mar 17, 2015

Upgrade Fails to Execute Update Tasks

Tagged:

upgrade-2.1

We recently attempted an upgrade from 1.6 to 1.12, and then to 2.1. The upgrade to 1.12 went fine, but we ran the upgrade script for 2.1, we started to see errors like these:

...
Do you wish to run all pending updates? (y/n): y
Executing hosting_alias_update_6203                                                                                      [success]
ALTER TABLE {hosting_site_alias} CHANGE `redirection` `redirection` VARCHAR(255) NOT NULL                                [success]
Executing hosting_alias_update_6204                                                                                      [success]
Unknown column 'db_name' in 'field list'                                                             [warning]
query: SELECT client, db_server, db_name, platform, profile, language as site_language, last_cron, cron_key, status AS
site_status, verified FROM hosting_site WHERE vid = 1065 database.mysqli.inc:134
...
Duplicate entry '127' for key 'PRIMARY'                                                              [warning]
query: UPDATE hosting_ip_addresses SET id=127 WHERE nid=707 AND ip_address='10.10.15.23'
database.mysqli.inc:134
...
UPDATE {hosting_ip_addresses} SET id=223 WHERE nid=836 AND ip_address='10.10.11.21'                 [error]
...

Even though the ALTER TABLE line above states it is a "success", examining the hosting_site_alias table, shows that the redirection field is still a TINYINT. Further, the error "Unknown column 'db_name' in 'field list'" error appears way before the ALTER TABLE for hosting_site table -- so there is some statements executed out of sequence, perhaps?

Anyone come across an issue like this during upgrade? How might one go about addressing these issues? We've checked DB permissions, and they are all fine -- after all the upgrade to 1.12 went fine. Nothing unusual on the DB server logs.

helmo

8:43am Mar 18, 2015

#1

Well, hosting_alias_update_6204() does call node_load which used the new db_name column. So we have to make sure that hosting_site_update_6202() runs before that.

I was already looking at hook_update_dependencies() but that only in D7... :(

The easiest fix is to manually manually add the db_name column as a varchar 64 in the hosting_site table and comment out the lines in hosting_site_update_6202() to prevent an error there.

3:45pm Mar 20, 2015

#2

In the seqence of events above, hosting_alias_update_6203 and hosting_alias_update_6204 run before hosting_site_update_6202.

It is a little disturbing that the scripts returns "success" for an update that did not occur, and runs an update out of order.

So you're telling me the upgrade script isn't working like it should? And that the updates need to run manually? Are there any options for debugging?

I've these changes, and various UPDATEs similar to what I posted above. Are there any other updates I need to run manually?

ALTER TABLE hosting_site_alias CHANGE `redirection` `redirection` VARCHAR(255) NOT NULL                                
ALTER TABLE hosting_context CHANGE `name` `name` VARCHAR(235) NOT NULL                                                 
ALTER TABLE hosting_package_instance ADD `platform` INT NOT NULL DEFAULT 0                                             
ALTER TABLE hosting_platform ADD `make_working_copy` INT unsigned NOT NULL DEFAULT 0                                   
ALTER TABLE hosting_platform DROP release_id                                                                           
ALTER TABLE hosting_ip_addresses DROP INDEX vid                                                                        
ALTER TABLE hosting_ip_addresses DROP vid                                                                              
ALTER TABLE hosting_ip_addresses ADD `id` INT unsigned auto_increment DEFAULT NULL, ADD PRIMARY KEY (id)               
ALTER TABLE hosting_ip_addresses CHANGE `id` `id` INT unsigned NOT NULL auto_increment                                 
ALTER TABLE hosting_ip_addresses ADD INDEX nid (nid)                                                                   

CREATE TABLE hosting_ssl_cert_ips
`cid` INT unsigned NOT NULL DEFAULT 0,
`ip_address` INT unsigned NOT NULL DEFAULT 0,
INDEX cid (cid),
INDEX ip_address (ip_address)
) /*!40100 DEFAULT CHARACTER SET utf8 */
Executing hosting_server_update_6202
INSERT INTO hosting_ssl_cert_ips (cid, ip_address)
  SELECT cert.cid,server_ip.id FROM hosting_ssl_site ssl_site
    INNER JOIN hosting_ssl_cert cert ON cert.cid = ssl_site.ssl_key
    INNER JOIN hosting_ip_addresses site_ip ON site_ip.nid = ssl_site.nid
    INNER JOIN hosting_site site ON site.nid = ssl_site.nid
    INNER JOIN hosting_ip_addresses server_ip ON server_ip.ip_address =
site_ip.ip_address
    INNER JOIN hosting_platform p ON site.platform = p.nid AND p.web_server
= server_ip.nid
    WHERE ssl_enabled > %d AND site.status > %d GROUP BY cid

ALTER TABLE hosting_site ADD `db_name` VARCHAR(64) NOT NULL DEFAULT ''

helmo

3:54pm Mar 20, 2015

#3

The 'problem' has been addressed in Drupal 7 by being able to specify in which order update hooks execute.

I don't think you need to run more updates manually, as e.g. hosting_alias_update_6203 does not call node_load.